January 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JBJCA-729) IronJacamar 1.0.7.Final

by Jesper Pedersen (Created) (JIRA)

IronJacamar 1.0.7.Final ----------------------- Key: JBJCA-729 URL: https://issues.jboss.org/browse/JBJCA-729 Project: IronJacamar Issue Type: Release Components: Build Reporter: Jesper Pedersen Assignee: Jesper Pedersen Fix For: 1.0.7.Final Release notes: https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12310691&versi... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 3 months

2
1
0 / 0

[JBoss JIRA] (JBJCA-721) Handled thread's interrupted status differently for call to java.sql.DataSource.getConnection()

by Justin Bertram (Created) (JIRA)

Handled thread's interrupted status differently for call to java.sql.DataSource.getConnection() ----------------------------------------------------------------------------------------------- Key: JBJCA-721 URL: https://issues.jboss.org/browse/JBJCA-721 Project: IronJacamar Issue Type: Bug Reporter: Justin Bertram Assignee: Jesper Pedersen Currently in org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.getConnection(Subject, ConnectionRequestInfo) if the calling thread has it's "interrupted" status set to "true" a ResourceException will be thrown. This can be confusing to users. Furthermore, the pool shouldn't care about the thread's interrupted status. The only reason the ResourceException is thrown is because getConnection ultimately accesses java.util.concurrent.Semaphore.tryAcquire(long, TimeUnit) which throws an InterruptedException if the thread's interrupted status is "true" (see http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/Semaphore.h...). We could either clear the thread's interrupted status by calling Thread.interrupted() without saving it or save it and restore the interrupted status back to the thread when the call is complete. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 3 months

4
3
0 / 0

[JBoss JIRA] (AS7-1338) Remote JNDI support for AS7

by Jason Greene (Commented) (JIRA)

[ https://issues.jboss.org/browse/AS7-1338?page=com.atlassian.jira.plugin.s... ] Jason Greene commented on AS7-1338: ----------------------------------- Hello Tobias, Since this is going to be over remoting, we are planning to share port 4447 for this (also used for EJB invocation). Also the port will be secured for the final release. > Remote JNDI support for AS7 > --------------------------- > > Key: AS7-1338 > URL: https://issues.jboss.org/browse/AS7-1338 > Project: Application Server 7 > Issue Type: Task > Components: Naming > Reporter: Richard Opalka > Assignee: John Bailey > Priority: Critical > Labels: eap6-req > Fix For: 7.1.0.Final > > > Add support for remote JNDI after all. It was agreed that: > * Remote JNDI would run over Remoting > * Remote JNDI for EJB is strictly a legacy access protocol, deprecated in favor of "ejb:" > * The Remote JNDI service would proxy to a specific Context of the server JNDI tree - maybe "java:jboss/shared", maybe something else > * Server-side services would opt-in to Remote JNDI; initially we'd only support: > ** Remote EJB interfaces > ** HornetQ connection factories > * In the future we may support: > ** User bindings, so long as they're serializable > * In the future we will never support: > ** Proxied DataSources > ** Proxied JMS invocations > Initial project tree is at https://github.com/dmlloyd/jboss-remote-jndi for now. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-727) Track component updates

by Jesper Pedersen (Created) (JIRA)

Track component updates ----------------------- Key: JBJCA-727 URL: https://issues.jboss.org/browse/JBJCA-727 Project: IronJacamar Issue Type: Task Components: Build Reporter: Jesper Pedersen Assignee: Jesper Pedersen Fix For: 1.0.7.Final -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-728) JBoss Transaction SPI 7.0.0.CR2

by Jesper Pedersen (Created) (JIRA)

JBoss Transaction SPI 7.0.0.CR2 ------------------------------- Key: JBJCA-728 URL: https://issues.jboss.org/browse/JBJCA-728 Project: IronJacamar Issue Type: Component Upgrade Components: Build Reporter: Jesper Pedersen Assignee: Jesper Pedersen Fix For: 1.0.7.Final -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-726) JBoss Transaction SPI 7.0.0.CR2

by Jesper Pedersen (Created) (JIRA)

JBoss Transaction SPI 7.0.0.CR2 ------------------------------- Key: JBJCA-726 URL: https://issues.jboss.org/browse/JBJCA-726 Project: IronJacamar Issue Type: Component Upgrade Components: Build Reporter: Jesper Pedersen Assignee: Jesper Pedersen Fix For: 1.1.0.Alpha5 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 3 months

1
0
0 / 0

[JBoss JIRA] (AS7-2986) ModuleClassLoader can't load HttpClient within a spring loaded bean using RESTEasy

by Michael Steffens (Created) (JIRA)

ModuleClassLoader can't load HttpClient within a spring loaded bean using RESTEasy ---------------------------------------------------------------------------------- Key: AS7-2986 URL: https://issues.jboss.org/browse/AS7-2986 Project: Application Server 7 Issue Type: Bug Components: Class Loading Affects Versions: 7.1.0.Beta1b Reporter: Michael Steffens Assignee: David Lloyd Can't instantiate a HttpClient within a spring loaded bean using RESTEasy. Depending on whether resteasy-jaxrs included in war archive (scope "compile") or not included (scope "provided"), the ModuleClassLoader is trapped by either a duplicate class object, or none at all. See http://community.jboss.org/message/640810 for further details and example code. Tried following workarounds, but failed: If you change the code not to instantiate HttpClient explicitly, as in private ClientExecutor createClientExecutor() { ClientExecutor clientExecutor = new ApacheHttpClient4Executor(); return clientExecutor; } the code runs fine. But then you can't attach Credentials (not acceptable). Or you need to query the ClientExecutor's HttpClient afterwards, and cast the result to DefautHttpClient -> Class loader issue is back again. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 3 months

4
3
0 / 0

[JBoss JIRA] (AS7-3177) Method expression parameters causes MethodNotFoundException

by Stian Thorgersen (Created) (JIRA)

Method expression parameters causes MethodNotFoundException ----------------------------------------------------------- Key: AS7-3177 URL: https://issues.jboss.org/browse/AS7-3177 Project: Application Server 7 Issue Type: Bug Affects Versions: 7.1.0.CR1b Reporter: Stian Thorgersen I have a web app that works in 7.0.2.Final, but doesn't work in 7.1.0.CR1b. The problem seems to be that method expression parameters no longer works. When trying to invoke a method with parameters the following exception is thrown: {code} 21:08:22,931 WARNING [javax.enterprise.resource.webcontainer.jsf.lifecycle] (http-localhost-127.0.0.1-8080-5) #{activeActions.select(active.parentId)}: java.lang.NullPointerException: javax.faces.FacesException: #{activeActions.select(active.serviceAgreement.parentId)}: java.lang.NullPointerException at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:110) [jsf-impl-2.1.5-jbossorg-1.jar:2.1.5-SNAPSHOT] at javax.faces.component.UICommand.broadcast(UICommand.java:315) [jboss-jsf-api_2.1_spec-2.0.0.Beta1.jar:2.0.0.Beta1] at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:794) [jboss-jsf-api_2.1_spec-2.0.0.Beta1.jar:2.0.0.Beta1] at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1259) [jboss-jsf-api_2.1_spec-2.0.0.Beta1.jar:2.0.0.Beta1] at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:81) [jsf-impl-2.1.5-jbossorg-1.jar:2.1.5-SNAPSHOT] at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.1.5-jbossorg-1.jar:2.1.5-SNAPSHOT] at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118) [jsf-impl-2.1.5-jbossorg-1.jar:2.1.5-SNAPSHOT] at javax.faces.webapp.FacesServlet.service(FacesServlet.java:593) [jboss-jsf-api_2.1_spec-2.0.0.Beta1.jar:2.0.0.Beta1] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329) [jbossweb-7.0.7.Final.jar:] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.7.Final.jar:] at org.jboss.weld.servlet.ConversationPropagationFilter.doFilter(ConversationPropagationFilter.java:62) [weld-core-1.1.4.Final.jar:2011-11-22 20:01] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280) [jbossweb-7.0.7.Final.jar:] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.7.Final.jar:] at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [jbossweb-7.0.7.Final.jar:] at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) [jbossweb-7.0.7.Final.jar:] at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:489) [jbossweb-7.0.7.Final.jar:] at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:151) [jboss-as-web-7.1.0.CR1b.jar:7.1.0.CR1b] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) [jbossweb-7.0.7.Final.jar:] at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.7.Final.jar:] at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.7.Final.jar:] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [jbossweb-7.0.7.Final.jar:] at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:897) [jbossweb-7.0.7.Final.jar:] at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:626) [jbossweb-7.0.7.Final.jar:] at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:2033) [jbossweb-7.0.7.Final.jar:] at java.lang.Thread.run(Thread.java:679) [:1.6.0_23] Caused by: javax.faces.el.MethodNotFoundException: java.lang.NullPointerException at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:104) [jboss-jsf-api_2.1_spec-2.0.0.Beta1.jar:2.0.0.Beta1] at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:102) [jsf-impl-2.1.5-jbossorg-1.jar:2.1.5-SNAPSHOT] ... 24 more Caused by: java.lang.NullPointerException at java.lang.Class.isAssignableFrom(Native Method) [:1.6.0_23] at org.apache.el.util.ReflectionUtil.isAssignableFrom(ReflectionUtil.java:299) [jbossweb-7.0.7.Final.jar:] at org.apache.el.util.ReflectionUtil.getMethod(ReflectionUtil.java:172) [jbossweb-7.0.7.Final.jar:] at org.apache.el.parser.AstValue.invoke(AstValue.java:251) [jbossweb-7.0.7.Final.jar:] at org.apache.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:278) [jbossweb-7.0.7.Final.jar:] at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:39) [weld-core-1.1.4.Final.jar:2011-11-22 20:01] at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50) [weld-core-1.1.4.Final.jar:2011-11-22 20:01] at com.sun.faces.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:105) [jsf-impl-2.1.5-jbossorg-1.jar:2.1.5-SNAPSHOT] at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:88) [jboss-jsf-api_2.1_spec-2.0.0.Beta1.jar:2.0.0.Beta1] ... 25 more {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 3 months

6
13
0 / 0

[JBoss JIRA] Created: (AS7-1982) CLI reports incorrect access-type, value-type, restart-required values

by Thomas Diesler (JIRA)

CLI reports incorrect access-type, value-type, restart-required values ---------------------------------------------------------------------- Key: AS7-1982 URL: https://issues.jboss.org/browse/AS7-1982 Project: Application Server 7 Issue Type: Bug Reporter: Thomas Diesler read-resource-description reports attribute values that are different from what is specified in code. Below in brackets the expected value {code} [standalone@localhost:9999 /] /subsystem=osgi:read-resource-description(recursive=true) { "outcome" => "success", "result" => { "description" => "The the OSGi subsystem configuration.", "head-comment-allowed" => true, "tail-comment-allowed" => true, "namespace" => "urn:jboss:domain:osgi:1.0", "attributes" => {"activation" => { "description" => "Activation flag for the OSGi subsystem. Possible values: lazy, eager.", "type" => STRING, "default" => "LAZY", "access-type" => "read-write", [RESTART_JVM] "restart-required" => "no-services", "storage" => "configuration" }}, "children" => { "configuration" => { "description" => "A configuration entry.", "model-description" => {"*" => { "description" => "A configuration entry.", "attributes" => {"entries" => { "description" => "The list of configuration entries.", "required" => true, "type" => LIST, [PROPERTY] "value-type" => UNDEFINED, [read-write] "access-type" => "read-only", "restart-required" => "RESTART_ALL_SERVICES", "storage" => "configuration" }} }} }, "framework-property" => { "description" => "A framework property.", "model-description" => {"*" => { "description" => "A framework property.", "attributes" => {"value" => { "description" => "The framework property value.", "type" => STRING, "required" => true, [read-write] "access-type" => "read-only", "restart-required" => "RESTART_ALL_SERVICES", "storage" => "configuration" }} }} }, "capability" => { "description" => "A framework capability.", "model-description" => {"*" => { "description" => "A framework capability.", "attributes" => {"startlevel" => { "description" => "The startlevel for the capability.", "type" => INT, "required" => false, [read-write] "access-type" => "read-only", "restart-required" => "RESTART_ALL_SERVICES", "storage" => "configuration" }} }} } } } } {code} See the description setup in [OSGiSubsystemProviders|https://github.com/tdiesler/jboss-as/blob/0a02801a...] -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 3 months

5
8
0 / 0

[JBoss JIRA] (AS7-3222) RESTEasy: Ambiguity constructors of Resource aren't reported

by Pavel Janousek (Commented) (JIRA)

[ https://issues.jboss.org/browse/AS7-3222?page=com.atlassian.jira.plugin.s... ] Pavel Janousek commented on AS7-3222: ------------------------------------- Hi Weinen, sure, I've looked for Resource which satisfied only condition for ambiguity constructors, my example maybe isn't the best source of code for this type cases, but it can demonstrate the problem. So the code: {code} @Path("/err4") public class HelloWorldResourceInvalid4 { private int id = 1; @SuppressWarnings("unused") private HelloWorldResourceInvalid4() { id = 1; } public HelloWorldResourceInvalid4(@Context UriInfo ui) { id = 2; } public HelloWorldResourceInvalid4(@DefaultValue("q") @QueryParam("p") String p) { id = 3; } @GET @Path("/msg/{msg}") public String getMessage1() { return "Hello World!"+id; } } {code} When I switch zero argument constructor to private, usually was invoked public HelloWorldResourceInvalid4(@Context UriInfo ui), I've tried also add another constructor{code} public HelloWorldResourceInvalid4(@Context UriInfo ui, @DefaultValue("q") @QueryParam("p") String p) { id = 4; } {code} As specs says - "the most parametric constructor" must be used. It works fine. When I switch this constructor to private again, usually was invoked contructor public HelloWorldResourceInvalid4(@DefaultValue("q") @QueryParam("p") String p). So behavior of impl. specific choosing some of suitable constructor is ok, but impl. should generate a warning in this situation as specs. requires. > RESTEasy: Ambiguity constructors of Resource aren't reported > ------------------------------------------------------------ > > Key: AS7-3222 > URL: https://issues.jboss.org/browse/AS7-3222 > Project: Application Server 7 > Issue Type: Bug > Components: REST > Affects Versions: 7.1.0.CR1b > Reporter: Pavel Janousek > Assignee: Weinan Li > Priority: Blocker > > Section 3.1.2. of JAX-RS specs says: > <cite> > A public constructor MAY include parameters annotated with one of the following: @Context, @Header-Param, @CookieParam, @MatrixParam, @QueryParam or @PathParam. However, depending on the resource class lifecycle and concurrency, per-request information may not make sense in a constructor. If more than one public constructor is suitable then an implementation MUST use the one with the most parameters. +Choosing amongst suitable constructors with the same number of parameters is implementation specific, implementations SHOULD generate a warning about such ambiguity.+ > <cite> > Actual behavior is that none of warning is generated and some of suitable constructor is chosen silently. This is against implemented specs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 3 months

1
0
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 January 2012