August 2010 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBBUILD-627) Move exo platform stuff to releases repository

by Paul Gier (JIRA)

Move exo platform stuff to releases repository ---------------------------------------------- Key: JBBUILD-627 URL: https://jira.jboss.org/browse/JBBUILD-627 Project: JBoss Build System Issue Type: Task Components: Artifact Repositories Reporter: Paul Gier Assignee: Paul Gier Fix For: Repository Support 2010 The exoplatform files (org.exoplatform) should be moved to the releases repository instead of the thirdparty-releases repository. Also there are some files in the old repository that wasn't moved to Nexus. http://repository.jboss.org/maven2/org/exoplatform/ws/exo.ws.frameworks.j... https://repository.jboss.org/nexus/content/repositories/thirdparty-releas... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 11 months

1
3
0 / 0

[JBoss JIRA] Commented: (JBAS-8276) Weld Extension vs. Tomcat deployer in JBoss 6

by Pete Muir (JIRA)

[ https://jira.jboss.org/browse/JBAS-8276?page=com.atlassian.jira.plugin.sy... ] Pete Muir commented on JBAS-8276: --------------------------------- Moved to JBoss AS. > Weld Extension vs. Tomcat deployer in JBoss 6 > --------------------------------------------- > > Key: JBAS-8276 > URL: https://jira.jboss.org/browse/JBAS-8276 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Weld/CDI > Affects Versions: 6.0.0.M4 > Reporter: Heiko Braun > > When I deploy a web application that contains CDI beans to JBoss6-M4 I can see that bean deployment being executed two times. First the CDI deployer kicks in, then Tomcat deployer re-deploys the war archive, which causes a second execution of the extension: > 12:20:34,082 INFO [org.jboss.weld.Version] WELD-000900 1.0.1 (SP4) > 12:20:34,516 INFO [org.jboss.errai.cdi.server.CDIExtensionPoints] Discovered Errai Service: class com.foo.server.HelloWorldService > 12:20:34,564 INFO [org.jboss.errai.cdi.server.CDIExtensionPoints] Register CDI component as MessageCallback: @Service @ApplicationScoped com.foo.server.HelloWorldService > 12:20:34,583 INFO [org.jboss.web.tomcat.service.deployers.TomcatDeployment] deploy, ctxPath=/funky-app > 12:20:34,720 INFO [org.jboss.resteasy.cdi.CdiInjectorFactory] Found BeanManager at java:comp/BeanManager > 12:20:39,776 INFO [org.jboss.web.tomcat.service.deployers.TomcatDeployment] undeploy, ctxPath=/funky-app > 12:20:40,246 INFO [org.jboss.weld.Version] WELD-000900 1.0.1 (SP4) > 12:20:40,733 INFO [org.jboss.errai.cdi.server.CDIExtensionPoints] Discovered Errai Service: class com.foo.server.HelloWorldService > 12:20:40,844 INFO [org.jboss.errai.cdi.server.CDIExtensionPoints] Register CDI component as MessageCallback: @Service @ApplicationScoped com.foo.server.HelloWorldService > 12:20:40,856 INFO [org.jboss.web.tomcat.service.deployers.TomcatDeployment] deploy, ctxPath=/funky-app > 12:20:40,929 INFO [org.jboss.resteasy.cdi.CdiInjectorFactory] Found BeanManager at java:comp/BeanManager > Shouldn't it be the execution the extension tight to the tomcat deployer lifecycle? I.e. be dependent on it's meta data? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 11 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-8276) Weld Extension vs. Tomcat deployer in JBoss 6

by Pete Muir (JIRA)

[ https://jira.jboss.org/browse/JBAS-8276?page=com.atlassian.jira.plugin.sy... ] Pete Muir updated JBAS-8276: ---------------------------- Assignee: Marius Bogoevici Component/s: Weld/CDI > Weld Extension vs. Tomcat deployer in JBoss 6 > --------------------------------------------- > > Key: JBAS-8276 > URL: https://jira.jboss.org/browse/JBAS-8276 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Weld/CDI > Affects Versions: 6.0.0.M4 > Reporter: Heiko Braun > Assignee: Marius Bogoevici > > When I deploy a web application that contains CDI beans to JBoss6-M4 I can see that bean deployment being executed two times. First the CDI deployer kicks in, then Tomcat deployer re-deploys the war archive, which causes a second execution of the extension: > 12:20:34,082 INFO [org.jboss.weld.Version] WELD-000900 1.0.1 (SP4) > 12:20:34,516 INFO [org.jboss.errai.cdi.server.CDIExtensionPoints] Discovered Errai Service: class com.foo.server.HelloWorldService > 12:20:34,564 INFO [org.jboss.errai.cdi.server.CDIExtensionPoints] Register CDI component as MessageCallback: @Service @ApplicationScoped com.foo.server.HelloWorldService > 12:20:34,583 INFO [org.jboss.web.tomcat.service.deployers.TomcatDeployment] deploy, ctxPath=/funky-app > 12:20:34,720 INFO [org.jboss.resteasy.cdi.CdiInjectorFactory] Found BeanManager at java:comp/BeanManager > 12:20:39,776 INFO [org.jboss.web.tomcat.service.deployers.TomcatDeployment] undeploy, ctxPath=/funky-app > 12:20:40,246 INFO [org.jboss.weld.Version] WELD-000900 1.0.1 (SP4) > 12:20:40,733 INFO [org.jboss.errai.cdi.server.CDIExtensionPoints] Discovered Errai Service: class com.foo.server.HelloWorldService > 12:20:40,844 INFO [org.jboss.errai.cdi.server.CDIExtensionPoints] Register CDI component as MessageCallback: @Service @ApplicationScoped com.foo.server.HelloWorldService > 12:20:40,856 INFO [org.jboss.web.tomcat.service.deployers.TomcatDeployment] deploy, ctxPath=/funky-app > 12:20:40,929 INFO [org.jboss.resteasy.cdi.CdiInjectorFactory] Found BeanManager at java:comp/BeanManager > Shouldn't it be the execution the extension tight to the tomcat deployer lifecycle? I.e. be dependent on it's meta data? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 11 months

1
0
0 / 0

[JBoss JIRA] Moved: (JBAS-8276) Weld Extension vs. Tomcat deployer in JBoss 6

by Pete Muir (JIRA)

[ https://jira.jboss.org/browse/JBAS-8276?page=com.atlassian.jira.plugin.sy... ] Pete Muir moved WELD-578 to JBAS-8276: -------------------------------------- Project: JBoss Application Server (was: Weld) Key: JBAS-8276 (was: WELD-578) Affects Version/s: 6.0.0.M4 (was: 1.0.1.Final) Security: Public > Weld Extension vs. Tomcat deployer in JBoss 6 > --------------------------------------------- > > Key: JBAS-8276 > URL: https://jira.jboss.org/browse/JBAS-8276 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 6.0.0.M4 > Reporter: Heiko Braun > > When I deploy a web application that contains CDI beans to JBoss6-M4 I can see that bean deployment being executed two times. First the CDI deployer kicks in, then Tomcat deployer re-deploys the war archive, which causes a second execution of the extension: > 12:20:34,082 INFO [org.jboss.weld.Version] WELD-000900 1.0.1 (SP4) > 12:20:34,516 INFO [org.jboss.errai.cdi.server.CDIExtensionPoints] Discovered Errai Service: class com.foo.server.HelloWorldService > 12:20:34,564 INFO [org.jboss.errai.cdi.server.CDIExtensionPoints] Register CDI component as MessageCallback: @Service @ApplicationScoped com.foo.server.HelloWorldService > 12:20:34,583 INFO [org.jboss.web.tomcat.service.deployers.TomcatDeployment] deploy, ctxPath=/funky-app > 12:20:34,720 INFO [org.jboss.resteasy.cdi.CdiInjectorFactory] Found BeanManager at java:comp/BeanManager > 12:20:39,776 INFO [org.jboss.web.tomcat.service.deployers.TomcatDeployment] undeploy, ctxPath=/funky-app > 12:20:40,246 INFO [org.jboss.weld.Version] WELD-000900 1.0.1 (SP4) > 12:20:40,733 INFO [org.jboss.errai.cdi.server.CDIExtensionPoints] Discovered Errai Service: class com.foo.server.HelloWorldService > 12:20:40,844 INFO [org.jboss.errai.cdi.server.CDIExtensionPoints] Register CDI component as MessageCallback: @Service @ApplicationScoped com.foo.server.HelloWorldService > 12:20:40,856 INFO [org.jboss.web.tomcat.service.deployers.TomcatDeployment] deploy, ctxPath=/funky-app > 12:20:40,929 INFO [org.jboss.resteasy.cdi.CdiInjectorFactory] Found BeanManager at java:comp/BeanManager > Shouldn't it be the execution the extension tight to the tomcat deployer lifecycle? I.e. be dependent on it's meta data? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 11 months

1
0
0 / 0

[JBoss JIRA] Created: (JBCOMMON-82) FileUrlConnection can leak file descriptors

by Nikolay Tsankov (JIRA)

FileUrlConnection can leak file descriptors ------------------------------------------- Key: JBCOMMON-82 URL: https://jira.jboss.org/jira/browse/JBCOMMON-82 Project: JBoss Common Issue Type: Bug Security Level: Public (Everyone can see) Components: common-core (2.x) Environment: jdk 1.6 Reporter: Nikolay Tsankov The following code demonstrates the problem, I would suggest storing the FileInputStream on first call of getInputStream() and return it on subsequent calls : import java.io.File; import java.io.FileOutputStream; import java.io.InputStream; import java.io.OutputStream; import org.jboss.net.protocol.file.FileURLConnection; public class FileUrlConnectionBug { static File dir = new File("C:/test_file_url_connection"); public static void main(String[] args) throws Exception { File tmp = makeFile("file.txt"); FileURLConnection connection = new FileURLConnection(tmp.toURI().toURL()); InputStream inputStream = connection.getInputStream(); //get the content, which is also an input stream //calling this method causes getInputStream() to be called twice, see getContent() //in java.net.URLConnection InputStream contentInputStream = (InputStream) connection.getContent(); //close both streams inputStream.close(); contentInputStream.close(); //file cannot be deleted, as there is an open file descriptor left if (!tmp.delete()) { System.err.println("Streams closed, but file cannot be deleted after getContent() is called"); } //When getContent() is not called, everything is ok, file can be deleted File tmpOk = makeFile("fileOk.txt"); FileURLConnection connectionOk = new FileURLConnection(tmpOk.toURI().toURL()); InputStream inputStreamOk = connectionOk.getInputStream(); inputStreamOk.close(); if (tmpOk.delete()) { System.out.println("File deleted ok if getContent() is not called"); } } private static File makeFile(String name) throws Exception { dir.mkdir(); File tmp = new File(dir, name); OutputStream out = new FileOutputStream(tmp); out.write(1); out.close(); return tmp; } } -- 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, 11 months

2
2
0 / 0

[JBoss JIRA] Created: (RELOADED-9) JNDI standardized namespaces

by Carlo de Wolf (JIRA)

JNDI standardized namespaces ---------------------------- Key: RELOADED-9 URL: https://jira.jboss.org/jira/browse/RELOADED-9 Project: JBoss Reloaded Issue Type: Feature Request Reporter: Carlo de Wolf Assignee: Carlo de Wolf -- 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, 11 months

1
4
0 / 0

[JBoss JIRA] Created: (RELOADED-12) Create name space deployers

by Carlo de Wolf (JIRA)

Create name space deployers --------------------------- Key: RELOADED-12 URL: https://jira.jboss.org/jira/browse/RELOADED-12 Project: JBoss Reloaded Issue Type: Feature Request Reporter: Carlo de Wolf Assignee: Carlo de Wolf -- 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, 11 months

1
2
0 / 0

[JBoss JIRA] Created: (JBREM-1230) Client hangs when hitting MaxPoolSize with idleTimeout

by Takayoshi Kimura (JIRA)

Client hangs when hitting MaxPoolSize with idleTimeout ------------------------------------------------------ Key: JBREM-1230 URL: https://jira.jboss.org/browse/JBREM-1230 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.2.3.SP1, 2.2.2.SP9 Reporter: Takayoshi Kimura 1. In SocketServerInvoker.processInvocation(), clientpool.wait() is called when hitting MaxPoolSize 2. SocketServerInvoker$IdleTimerTask calls ServerThread.shutdown() and remove it from clientpool when it's timed out in idle state 3. ServerThread.shutdown() doesn't call clientpool.notify(), so #1 doesn't resume although there is free slot available -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 12 months

2
3
0 / 0

[JBoss JIRA] Created: (JBRULES-1859) Error info not telling root cause

by Jaroslaw Kijanowski (JIRA)

Error info not telling root cause --------------------------------- Key: JBRULES-1859 URL: https://jira.jboss.org/jira/browse/JBRULES-1859 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-guvnor Affects Versions: 5.0.0.M3 Reporter: Jaroslaw Kijanowski Assignee: Michael Neale When I: - create/copy a package and provide an already used name - create/copy a snapshot and provide an already used name - create/rename a status and provide an already used name I get an error window displayed: "The call failed on the server; see server log for details" Users may have no access to the server log. Moreover these errors are not reflected in the Event.log Finally, when I create a rule with a name that is already used, no information is displayed. -- 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, 12 months

6
13
0 / 0

[JBoss JIRA] Created: (JBRULES-2607) Nullpointer and/or incrorrect object for identifier when using live query rows

by Mark Proctor (JIRA)

Nullpointer and/or incrorrect object for identifier when using live query rows ------------------------------------------------------------------------------ Key: JBRULES-2607 URL: https://jira.jboss.org/browse/JBRULES-2607 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-core (expert) Affects Versions: 5.1.0.CR1 Reporter: Mark Proctor Assignee: Mark Proctor Fix For: 5.2.0.M1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 12 months

1
2
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 August 2010