[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
12 years, 5 months
[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
12 years, 5 months
[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
12 years, 5 months
[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
12 years, 5 months
[JBoss JIRA] (JBRULES-3338) Accuracy lost when comparing numbers
by Miles Wen (Created) (JIRA)
Accuracy lost when comparing numbers
------------------------------------
Key: JBRULES-3338
URL: https://issues.jboss.org/browse/JBRULES-3338
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-core (expert)
Affects Versions: 5.3.0.Final
Environment: sun jdk 1.6u27, drools 5.3.0 final
Reporter: Miles Wen
Assignee: Mark Proctor
Accuracy lost when comparing two numbers which has different number types. for example:
I have a pojo fact class 'Msg.java', and it has a int field named 'intVal', which value is inited 5.
And I write down this rule and run with default settings:
rule "out"
when
Msg(intVal == 5.5)
then
end
this rule would fire! but it shouldn't, cause 5 != 5.5.
It seems that drools converts the second operand of a comparison to the type of the first, no matter what the first number's type is. This definitely caused some accuracy lost in many cases.
if I wrote Msg(5.5 == intVal), the code behaves correctly.
--
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
12 years, 5 months
[JBoss JIRA] (AS7-3222) RESTEasy: Ambiguity constructors of Resource aren't reported
by Weinan Li (Commented) (JIRA)
[ https://issues.jboss.org/browse/AS7-3222?page=com.atlassian.jira.plugin.s... ]
Weinan Li commented on AS7-3222:
--------------------------------
Hi Pavel, could you please paste your java class with the ambiguous constructors so I could investigate on this one? Thanks!
> 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
12 years, 5 months
[JBoss JIRA] (AS7-3222) RESTEasy: Ambiguity constructors of Resource aren't reported
by Pavel Janousek (Moved) (JIRA)
[ https://issues.jboss.org/browse/AS7-3222?page=com.atlassian.jira.plugin.s... ]
Pavel Janousek moved JBPAPP-7878 to AS7-3222:
---------------------------------------------
Project: Application Server 7 (was: JBoss Enterprise Application Platform)
Key: AS7-3222 (was: JBPAPP-7878)
Workflow: GIT Pull Request workflow (was: jira)
Affects Version/s: 7.1.0.CR1b
(was: EAP 6.0.0 DR 9)
Component/s: REST
(was: RESTEasy)
Security: (was: JBoss Internal)
Docs QE Status: (was: NEW)
> 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
12 years, 5 months
[JBoss JIRA] (AS7-1338) Remote JNDI support for AS7
by Tobias Frech (Commented) (JIRA)
[ https://issues.jboss.org/browse/AS7-1338?page=com.atlassian.jira.plugin.s... ]
Tobias Frech commented on AS7-1338:
-----------------------------------
If the jndi.properties file on the client needs to be adapted for AS 7 (I guess so), it also could be discussed if the port 1099 is changed. On one hand this port maybe be already open on firewalls for remote clients to access the AS. On the other hand on Windows you could experience problems with this port because it is already used by a mounted share.
Also it would be nice if the implementation would allow to securely expose JNDI to the internet without risking someone unauthorized accessing and changing anything in it.
> 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
12 years, 5 months