June 2011 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (AS7-954) Exclude all transitive dependencies that are not automatically excluded

by Paul Gier (JIRA)

Exclude all transitive dependencies that are not automatically excluded ----------------------------------------------------------------------- Key: AS7-954 URL: https://issues.jboss.org/browse/AS7-954 Project: Application Server 7 Issue Type: Task Components: Build System Reporter: Paul Gier Fix For: 7.0.0.CR1 Currently the AS7 build is pulling in some unwanted transitive dependencies. Only dependencies listed in the dependencyManagement section of the root pom.xml should be brought into the build. The dependency tree should be compared to the list of deps in the root pom, and then exclude the ones we don't want. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 1 month

1
3
0 / 0

[JBoss JIRA] Created: (AS7-979) Upgrade to Hibernate 4.0.0.Beta1

by Scott Marlow (JIRA)

Upgrade to Hibernate 4.0.0.Beta1 -------------------------------- Key: AS7-979 URL: https://issues.jboss.org/browse/AS7-979 Project: Application Server 7 Issue Type: Task Components: JPA / Hibernate Reporter: Scott Marlow Assignee: Scott Marlow Fix For: 7.0.0.CR1 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 1 month

1
2
0 / 0

[JBoss JIRA] Created: (JBVFS-155) Add utility to generate a virtual jar/zip file input stream from a VFS directory

by John Bailey (JIRA)

Add utility to generate a virtual jar/zip file input stream from a VFS directory -------------------------------------------------------------------------------- Key: JBVFS-155 URL: https://jira.jboss.org/jira/browse/JBVFS-155 Project: JBoss VFS Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 3.0.0.CR5 Reporter: John Bailey Assignee: John Bailey Fix For: 3.0.0.CR6 This should allow someone with a VFS directory to get an InputStream that will produce a stream of bytes according to the zip specification. This should only be used by 3rd party frameworks that require an actual input stream to an archive for integration. -- 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, 1 month

2
1
0 / 0

[JBoss JIRA] Created: (JBVFS-169) Fix VirtualFile::toURL

by Ales Justin (JIRA)

Fix VirtualFile::toURL ---------------------- Key: JBVFS-169 URL: https://issues.jboss.org/browse/JBVFS-169 Project: JBoss VFS Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 3.0.0.CR5 Reporter: Ales Justin Assignee: Ales Justin Fix For: 3.0.0.CR6 Current VirtualFile::toURL fails on paths with spaces. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 1 month

2
1
0 / 0

[JBoss JIRA] Created: (JBVFS-147) Cannot read from vfs: protocol URL

by Thomas Diesler (JIRA)

Cannot read from vfs: protocol URL ---------------------------------- Key: JBVFS-147 URL: https://jira.jboss.org/jira/browse/JBVFS-147 Project: JBoss VFS Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 3.0.0.CR3 Reporter: Thomas Diesler Assignee: John Bailey Fix For: 3.0.0.CR4 Cannot read bytes from vfs: protocol URL URL url = new URL("vfs:/home/tdiesler/svn/jboss-osgi/projects/testing/trunk/target/test-libs/example-simple.jar/"); URLConnection con = (URLConnection)url.openConnection(); InputStream inputStream = con.getInputStream(); int read = inputStream.read(); read is -1 -- 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, 1 month

3
15
0 / 0

[JBoss JIRA] Created: (JBRULES-3055) [regression in 5.2.0.CR1] rulebuilder fails on eval() with &&

by Roman Novak (JIRA)

[regression in 5.2.0.CR1] rulebuilder fails on eval() with && -------------------------------------------------------------- Key: JBRULES-3055 URL: https://issues.jboss.org/browse/JBRULES-3055 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 5.2.0.CR1 Reporter: Roman Novak Assignee: Mark Proctor Priority: Blocker the part in the rule from --> && timeInterval.overlaps($mbo1.getTimeInterval()) on causes the stacktrace below dialect "java" rule "mediumSujetOverlap" when $mbo1 : MediumBookingOpt ( moveable == true ) $mbo2 : MediumBookingOpt ( mediId == $mbo1.mediId, meboId > $mbo1.meboId, eval(indexRange.overlaps($mbo1.getIndexRange()) && timeInterval.overlaps($mbo1.getTimeInterval()))) then // end java.util.ConcurrentModificationException at java.util.HashMap$HashIterator.nextEntry(HashMap.java:793) at java.util.HashMap$KeyIterator.next(HashMap.java:828) at org.drools.rule.builder.PatternBuilder.createImplicitBindings(PatternBuilder.java:916) at org.drools.rule.builder.PatternBuilder.buildEval(PatternBuilder.java:844) at org.drools.rule.builder.PatternBuilder.build(PatternBuilder.java:397) at org.drools.rule.builder.PatternBuilder.build(PatternBuilder.java:261) at org.drools.rule.builder.PatternBuilder.build(PatternBuilder.java:67) at org.drools.rule.builder.GroupElementBuilder.build(GroupElementBuilder.java:65) at org.drools.rule.builder.RuleBuilder.build(RuleBuilder.java:81) at org.drools.compiler.PackageBuilder.addRule(PackageBuilder.java:1723) at org.drools.compiler.PackageBuilder.addPackage(PackageBuilder.java:699) at org.drools.compiler.PackageBuilder.addPackageFromDrl(PackageBuilder.java:302) at org.drools.planner.config.AbstractSolverConfig.buildRuleBase(AbstractSolverConfig.java:155) at org.drools.planner.config.AbstractSolverConfig.configureAbstractSolver(AbstractSolverConfig.java:130) at org.drools.planner.config.localsearch.LocalSearchSolverConfig.buildSolver(LocalSearchSolverConfig.java:101) at org.drools.planner.config.localsearch.LocalSearchSolverConfig.buildSolver(LocalSearchSolverConfig.java:33) at org.drools.planner.config.XmlSolverConfigurer.buildSolver(XmlSolverConfigurer.java:92) at BasicRegressionTest.testReplay1156(BasicRegressionTest.java:135) 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:597) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.springframework.test.context.junit4.statements.RunBeforeTestMethodCallbacks.evaluate(RunBeforeTestMethodCallbacks.java:74) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31) at org.springframework.test.context.junit4.statements.RunAfterTestMethodCallbacks.evaluate(RunAfterTestMethodCallbacks.java:82) at org.springframework.test.context.junit4.statements.SpringRepeat.evaluate(SpringRepeat.java:72) at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:240) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:44) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:180) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:41) at org.junit.runners.ParentRunner$1.evaluate(ParentRunner.java:173) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:61) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31) at org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:70) at org.junit.runners.ParentRunner.run(ParentRunner.java:220) at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:180) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:49) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 1 month

4
13
0 / 0

[JBoss JIRA] Created: (JBJCA-595) IronJacamar 1.0.0.CR1

by Jesper Pedersen (JIRA)

IronJacamar 1.0.0.CR1 --------------------- Key: JBJCA-595 URL: https://issues.jboss.org/browse/JBJCA-595 Project: IronJacamar Issue Type: Release Components: Build Reporter: Jesper Pedersen Assignee: Jesper Pedersen Fix For: 1.0.0.CR1 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 1 month

1
2
0 / 0

[JBoss JIRA] Created: (JBREM-1293) ServerThread pool should be treated like a stack

by Ron Sigal (JIRA)

ServerThread pool should be treated like a stack ------------------------------------------------ Key: JBREM-1293 URL: https://issues.jboss.org/browse/JBREM-1293 Project: JBoss Remoting Issue Type: Enhancement Security Level: Public (Everyone can see) Affects Versions: 2.2.4, 2.5.4.SP2 Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.2.4.SP1, 2.5.4.SP3 Currently, org.jboss.remoting.transport.socket.SocketServerInvoker.threadPool, which holds instances of org.jboss.remoting.transport.socket.ServerThread which are not currently servicing a socket, is treated as a queue. In particular, when a ServerThread is taken from threadPool, the least recently used one is taken. As a result, more recently used ServerThreads sit in threadPool and may not be harvested by the IdleTimerTask. The following example by Justin Bertram illustrates: In the first minute of life, a remote application (the only application the server is serving) creates 10 simultaneous connections to the server. The server creates 10 threads to service these 10 connections. However, throughout the rest of the life of the application it only uses 1 connection at a time, but it does so frequently (i.e. less than the idle timeout for the server-side threads). Let's say, for example, that the idle timeout is 3 minutes and the application connects and then disconnects every 10 seconds. With the current design that would keep those 10 threads alive indefinitely because none of them would ever be idle for more than 3 minutes. However, with the suggested change [i.e., treating threadPool like a stack] the client would always be served by the same thread which would allow the other 9 threads to timeout. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 1 month

1
3
0 / 0

[JBoss JIRA] Created: (JBJCA-592) i18n/l10n logging

by Jesper Pedersen (JIRA)

i18n/l10n logging ----------------- Key: JBJCA-592 URL: https://issues.jboss.org/browse/JBJCA-592 Project: IronJacamar Issue Type: Task Reporter: Jesper Pedersen Assignee: Jesper Pedersen Fix For: 1.0.0.CR1 Switch the logging of the project to the new i18n/l10n functionality. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 1 month

1
2
0 / 0

[JBoss JIRA] Created: (AS7-936) Ensure management interfaces are on a loopback interface not shared by general app server services

by Darran Lofthouse (JIRA)

Ensure management interfaces are on a loopback interface not shared by general app server services -------------------------------------------------------------------------------------------------- Key: AS7-936 URL: https://issues.jboss.org/browse/AS7-936 Project: Application Server 7 Issue Type: Task Components: Domain Management Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 7.0.0.CR1 The reason for this is so that when an administrator makes the app server services public e.g. JBoss Web to expose their web app they do not accidentally expose the management interfaces. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 1 month

2
5
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 June 2011