November 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-6041) CDI Decorator for a JAX-RS annotated interface results in WELD-001306

by Jozef Hartinger (JIRA)

[ https://issues.jboss.org/browse/AS7-6041?page=com.atlassian.jira.plugin.s... ] Jozef Hartinger moved WELD-1252 to AS7-6041: -------------------------------------------- Project: Application Server 7 (was: Weld) Key: AS7-6041 (was: WELD-1252) Workflow: GIT Pull Request workflow (was: jira) Affects Version/s: 7.1.1.Final (was: 1.1.5.Final) Fix Version/s: 7.2.0.Alpha1 (was: 2.0.0.CR1) > CDI Decorator for a JAX-RS annotated interface results in WELD-001306 > --------------------------------------------------------------------- > > Key: AS7-6041 > URL: https://issues.jboss.org/browse/AS7-6041 > Project: Application Server 7 > Issue Type: Bug > Affects Versions: 7.1.1.Final > Reporter: Daniel Sachse > Assignee: Jozef Hartinger > Fix For: 7.2.0.Alpha1 > > > I already bugged the Errai and Resteasy guys with my problem, but I was told that you guys are in charge of this ;) > I possibly discovered a bug in the Weld implementation provided with JBoss 7.1.1.Final. > I was playing around with Errai and JAX-RS and I discovered that when I add the JAX-RS annotations to the interface this works as expected. > As soon as I start to use a CDI Decorator with the JAX-RS interface, i start getting the following error: > "org.jboss.weld.exceptions.UnproxyableResolutionException: WELD-001306 Attempting to inject an unproxyable normal scoped bean Decorator….." > If I then put the JAX-RS annotations back at the implementation, everything works fine. Unfortunately this behavior is not working for me, because Errai needs the annotations at the interface to create client code. > As I was unsure if this only happened with Errai on the classpath, I created a very little demo project, which exactly shows the bug I mentioned: https://github.com/w0mbat/RESTTest -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

1
0
0 / 0

[JBoss JIRA] (AS7-6041) CDI Decorator for a JAX-RS annotated interface results in WELD-001306

by Jozef Hartinger (JIRA)

[ https://issues.jboss.org/browse/AS7-6041?page=com.atlassian.jira.plugin.s... ] Jozef Hartinger updated AS7-6041: --------------------------------- Assignee: Stuart Douglas (was: Jozef Hartinger) Component/s: REST > CDI Decorator for a JAX-RS annotated interface results in WELD-001306 > --------------------------------------------------------------------- > > Key: AS7-6041 > URL: https://issues.jboss.org/browse/AS7-6041 > Project: Application Server 7 > Issue Type: Bug > Components: REST > Affects Versions: 7.1.1.Final > Reporter: Daniel Sachse > Assignee: Stuart Douglas > Fix For: 7.2.0.Alpha1 > > > I already bugged the Errai and Resteasy guys with my problem, but I was told that you guys are in charge of this ;) > I possibly discovered a bug in the Weld implementation provided with JBoss 7.1.1.Final. > I was playing around with Errai and JAX-RS and I discovered that when I add the JAX-RS annotations to the interface this works as expected. > As soon as I start to use a CDI Decorator with the JAX-RS interface, i start getting the following error: > "org.jboss.weld.exceptions.UnproxyableResolutionException: WELD-001306 Attempting to inject an unproxyable normal scoped bean Decorator….." > If I then put the JAX-RS annotations back at the implementation, everything works fine. Unfortunately this behavior is not working for me, because Errai needs the annotations at the interface to create client code. > As I was unsure if this only happened with Errai on the classpath, I created a very little demo project, which exactly shows the bug I mentioned: https://github.com/w0mbat/RESTTest -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

1
0
0 / 0

[JBoss JIRA] (AS7-5889) Remote client EJB invocation hangs when a large String is passed as parameter

by Tom Ross (JIRA)

Tom Ross created AS7-5889: ----------------------------- Summary: Remote client EJB invocation hangs when a large String is passed as parameter Key: AS7-5889 URL: https://issues.jboss.org/browse/AS7-5889 Project: Application Server 7 Issue Type: Bug Components: EJB Affects Versions: 7.1.3.Final (EAP) Environment: EAP 6.01 ER3 Reporter: Tom Ross Assignee: jaikiran pai Priority: Critical When making an EJB invocation with a String parameter of length 600000 the invocation hangs and never returns. This seem to happen only with 6.01 code line running the test case against 6.1 does not show the problem. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

2
5
0 / 0

[JBoss JIRA] (AS7-5794) JMX over remoting pollutes query results with ModelController objects

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/AS7-5794?page=com.atlassian.jira.plugin.s... ] Tristan Tarrant commented on AS7-5794: -------------------------------------- [~kabirkhan] I haven't tested against 7.2.x yet. I will if I find some time > JMX over remoting pollutes query results with ModelController objects > --------------------------------------------------------------------- > > Key: AS7-5794 > URL: https://issues.jboss.org/browse/AS7-5794 > Project: Application Server 7 > Issue Type: Bug > Components: Domain Management, JMX > Affects Versions: 7.1.2.Final (EAP) > Reporter: Tristan Tarrant > Assignee: Kabir Khan > Fix For: 7.3.0.Alpha1 > > > When issuing MBean queries over JMX remoting, the AS is returning a list of org.jboss.as.controller.ModelController objects in addition to those matching the query. > This is a transcript of a chat we had about it on IRC: > Oct 15 14:51:46 <ttarrant> darranl, if I issue a jmx query over jmx-remoting I get many more objects than expected > Oct 15 14:51:55 <ttarrant> darranl, i.e. ones that do not match the query > Oct 15 14:52:09 <ttarrant> darranl, this is with 7.1.x > Oct 15 14:52:57 <ttarrant> darranl, this works if I use the standard JMX over RMI > Oct 15 14:53:08 --> fnasser (~fnasser(a)CPE602ad07ab726-CM602ad07ab723.cpe.net.cable.rogers.com) has joined #jboss-as7 > Oct 15 14:53:09 <-- fnasser has quit (Changing host) > Oct 15 14:53:09 --> fnasser (~fnasser@redhat/jboss/fnasser) has joined #jboss-as7 > Oct 15 14:53:09 --- ChanServ gives voice to fnasser > Oct 15 14:53:16 <ttarrant> darranl, do you just pass the query the the mbeanserver ? > Oct 15 14:53:39 <darranl> ttarrant: what kind of objects? within AS7 I think there are two things that could affec > t this 1 - The Remoting JMX protocol, 2 - The domain management representation over JMX > Oct 15 14:53:54 <darranl> For #1 yes we just pass it to the MBEanServer and return whatever it returns > Oct 15 14:54:04 <darranl> if it was a Remoting JMX bug maybe we are messing up the query > Oct 15 14:54:16 <ttarrant> darranl, the query is as follows: *:type=CacheManager,component=Interpreter,name=* > Oct 15 14:54:16 <darranl> But not sure if #2 could be the reason more is getting added > Oct 15 14:54:32 <ttarrant> darranl, wait a sec > Oct 15 14:54:57 <darranl> ttarrant: I would suggest getting a Jira raised and assigned to me, I can verify if it i > s a remoting jmx issue or pass over if it is a domain management integration issue > Oct 15 14:55:20 <darranl> regardless of where it is happenign it sounds like you may have discovered a bug > Oct 15 14:56:23 <ttarrant> darranl, let me get the objects it's returning > Oct 15 14:56:39 <darranl> ttarrant: when you enable the RMI approach you bypass both Remoting JMX AND the domain m > anagement integration > Oct 15 14:56:42 <darranl> ok > Oct 15 15:26:08 <ttarrant> darranl, ok, my query actually returns the object I queried for and a bunch of org.jboss.as.controller.ModelController (one for each subsystem) > Oct 15 15:51:24 <darranl> ttarrant: ok that does then sound like it is the domain management integration that is 'poluting' the query results > Oct 15 15:51:53 <darranl> ttarrant: going RMI was just bypassing that as well > Oct 15 15:52:05 <ttarrant> darranl, shall I open a Jira ? > Oct 15 15:52:34 <ttarrant> darranl, I work around the issue by manually filtering the returned objects based on class name > Oct 15 15:53:23 <darranl> ttarrant: it would probably be one for kkhan to look into, think he is just back today so may be worth the Jira so he can have a look once he has caught back up ;-) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

1
0
0 / 0

[JBoss JIRA] (AS7-5895) Using an annotation from a private api module does not result in a warning

by Carlo de Wolf (JIRA)

Carlo de Wolf created AS7-5895: ---------------------------------- Summary: Using an annotation from a private api module does not result in a warning Key: AS7-5895 URL: https://issues.jboss.org/browse/AS7-5895 Project: Application Server 7 Issue Type: Bug Reporter: Carlo de Wolf If an user deployment uses an annotation from a module that is marked as private there is no warning being emitted. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

2
3
0 / 0

[JBoss JIRA] (JBJCA-907) Eclipse plugin: Avoid adding config property value for ActivationSpec in resource adapter version 1.5

by Vladimir Rastseluev (JIRA)

Vladimir Rastseluev created JBJCA-907: ----------------------------------------- Summary: Eclipse plugin: Avoid adding config property value for ActivationSpec in resource adapter version 1.5 Key: JBJCA-907 URL: https://issues.jboss.org/browse/JBJCA-907 Project: IronJacamar Issue Type: Bug Components: Eclipse Affects Versions: 1.1.0.Beta2 Reporter: Vladimir Rastseluev Assignee: Jeff Zhang Fix For: 1.1.0.Beta3 Due to 1.5 specification schema, there is no possibility to add configuration property value to ActivationSpec class. Please, avoid it in eclipse plugin. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

3
6
0 / 0

[JBoss JIRA] (JBNAME-61) Remote JNDI lookup failure with sun.io.serialization.extendedDebugInfo

by Dennis Reed (JIRA)

Dennis Reed created JBNAME-61: --------------------------------- Summary: Remote JNDI lookup failure with sun.io.serialization.extendedDebugInfo Key: JBNAME-61 URL: https://issues.jboss.org/browse/JBNAME-61 Project: JBoss Naming Issue Type: Bug Components: jnp-client Affects Versions: 5.0.3.GA Reporter: Dennis Reed When the system property sun.io.serialization.extendedDebugInfo is set, a remote lookup fails with the exception: java.lang.UnsupportedOperationException at org.jnp.interfaces.FastNamingProperties.toString(FastNamingProperties.java:175) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1387) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:330) at javax.naming.CompoundName.writeObject(CompoundName.java:541) 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 java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:945) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1469) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1400) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:330) at sun.rmi.server.UnicastRef.marshalValue(UnicastRef.java:274) at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:133) at org.jnp.server.NamingServer_Stub.lookup(Unknown Source) at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:726) at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:686) at javax.naming.InitialContext.lookup(InitialContext.java:392) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

1
2
0 / 0

[JBoss JIRA] (AS7-5978) DefaultDeploymentOperations should use ModelControllerClient.executeAsync()

by Brian Stansberry (JIRA)

Brian Stansberry created AS7-5978: ------------------------------------- Summary: DefaultDeploymentOperations should use ModelControllerClient.executeAsync() Key: AS7-5978 URL: https://issues.jboss.org/browse/AS7-5978 Project: Application Server 7 Issue Type: Bug Components: Domain Management Affects Versions: 7.1.3.Final (EAP) Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: 7.2.0.Alpha1, 7.1.4.Final (EAP) DefaultDeploymentOperations isn't using the async ModelControllerClient API; instead it is submitting a synchronous execute request to its own Executor. It should use the ModelControllerClient.executeAsync() API to ensure the intended task cancellation logic is invoked. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

1
1
0 / 0

[JBoss JIRA] (AS7-6039) ServiceBasedNamingStore improperly resolves names when constructing RequireResolveException instances

by David Lloyd (JIRA)

David Lloyd created AS7-6039: -------------------------------- Summary: ServiceBasedNamingStore improperly resolves names when constructing RequireResolveException instances Key: AS7-6039 URL: https://issues.jboss.org/browse/AS7-6039 Project: Application Server 7 Issue Type: Bug Components: Naming Reporter: David Lloyd Assignee: David Lloyd Fix For: 7.2.0.Alpha1, 7.1.4.Final (EAP) The org.jboss.as.naming.ServiceBasedNamingStore#convert() method does not consider the serviceNameBase of the store, resulting in an incorrect JNDI base name being reported. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

1
0
0 / 0

[JBoss JIRA] (AS7-5403) CLONE - Adding modcluster via the CLI fails.

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/AS7-5403?page=com.atlassian.jira.plugin.s... ] Brian Stansberry commented on AS7-5403: --------------------------------------- Have you seen https://github.com/jbossas/jboss-as/pull/3201 ? That's been sitting there for a long time because I haven't had time to deal with it. > CLONE - Adding modcluster via the CLI fails. > -------------------------------------------- > > Key: AS7-5403 > URL: https://issues.jboss.org/browse/AS7-5403 > Project: Application Server 7 > Issue Type: Bug > Components: CLI > Affects Versions: 7.1.2.Final (EAP) > Reporter: Tom Fonteyne > Assignee: Joe Wertz > Fix For: 7.2.0.Alpha1 > > > Adding modcluster via the CLI fails. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira November 2012