January 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-3162) RESTEasy: Unknown servet name javax.ws.rs.core.Application when javax.ws.rs.core.Application subclass is on classpath

by Weinan Li (Commented) (JIRA)

[ https://issues.jboss.org/browse/AS7-3162?page=com.atlassian.jira.plugin.s... ] Weinan Li commented on AS7-3162: -------------------------------- As Stuart suggested, I'll improve the error log for this scenario. > RESTEasy: Unknown servet name javax.ws.rs.core.Application when javax.ws.rs.core.Application subclass is on classpath > ---------------------------------------------------------------------------------------------------------------------- > > Key: AS7-3162 > URL: https://issues.jboss.org/browse/AS7-3162 > Project: Application Server 7 > Issue Type: Bug > Components: REST > Affects Versions: 7.1.0.CR1b > Reporter: Pavel Janousek > Assignee: Weinan Li > Priority: Blocker > > I've deployment like this: > {code} > @Deployment > public static Archive<?> deploy() { > WebArchive war = ShrinkWrap.create(WebArchive.class, "jaxrsnoap.war"); > war.addPackage(HttpRequest.class.getPackage()); > war.addClasses(ApplicationTestCase.class, ApplicationInvalid1.class); > war.addAsWebInfResource( > WebXml.get("<servlet-mapping>\n" > + " <servlet-name>javax.ws.rs.core.Application</servlet-name>\n" > + " <url-pattern>/myjaxrs/*</url-pattern>\n" > + "</servlet-mapping>\n" + "\n"), "web.xml"); > return war; > } > {code} > This deployment fails during deploying because of "Context [/jaxrsnoap] startup failed due to previous errors: java.lang.IllegalArgumentException: Servlet mapping specifies an unknown servlet name javax.ws.rs.core.Application" > ApplicationInvalid1 is empty subclass of javax.ws.rs.core.Application like: > {code} > public class ApplicationInvalid1 extends Application { > private Set<Class<?>> classes = new HashSet<Class<?>>(); > public ApplicationInvalid1() { > } > @Override > public Set<Class<?>> getClasses() { > return classes; > } > } > {code} > There isn't any reference to this class in web.xml or somewhere else. Only class is placed on classpath. If I remove this class from deployment (= change appropriate line to "war.addClasses(ApplicationTestCase.class);", everything will be OK. -- 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-3162) RESTEasy: Unknown servet name javax.ws.rs.core.Application when javax.ws.rs.core.Application subclass is on classpath

by Weinan Li (Commented) (JIRA)

[ https://issues.jboss.org/browse/AS7-3162?page=com.atlassian.jira.plugin.s... ] Weinan Li commented on AS7-3162: -------------------------------- Stuart is correct. Thank you for explaining Stuart :-) Pavel, have you configured an @Application while you are using the config in web.xml? This shouldn't be used at same time. You should either use @Application + @ApplicationPath or use the traditional config method in web.xml. Mixing them up is neither correct in standalone or container deployment method. You can refer to org.jboss.as.jaxrs.deployment.JaxrsIntegrationProcessor for more details: {code:title=JaxrsIntegrationProcessor.java|borderStyle=solid} if (resteasy.getScannedApplicationClass() == null) { //if there is no scanned application we must add a servlet with a name of //javax.ws.rs.core.Application } else { //now there are two options. //if there is already a servlet defined with an init param //we don't do anything. //Otherwise we install our filter //JAVA-RS seems somewhat confused about the difference between a context param //and an init param. } {code} > RESTEasy: Unknown servet name javax.ws.rs.core.Application when javax.ws.rs.core.Application subclass is on classpath > ---------------------------------------------------------------------------------------------------------------------- > > Key: AS7-3162 > URL: https://issues.jboss.org/browse/AS7-3162 > Project: Application Server 7 > Issue Type: Bug > Components: REST > Affects Versions: 7.1.0.CR1b > Reporter: Pavel Janousek > Assignee: Weinan Li > Priority: Blocker > > I've deployment like this: > {code} > @Deployment > public static Archive<?> deploy() { > WebArchive war = ShrinkWrap.create(WebArchive.class, "jaxrsnoap.war"); > war.addPackage(HttpRequest.class.getPackage()); > war.addClasses(ApplicationTestCase.class, ApplicationInvalid1.class); > war.addAsWebInfResource( > WebXml.get("<servlet-mapping>\n" > + " <servlet-name>javax.ws.rs.core.Application</servlet-name>\n" > + " <url-pattern>/myjaxrs/*</url-pattern>\n" > + "</servlet-mapping>\n" + "\n"), "web.xml"); > return war; > } > {code} > This deployment fails during deploying because of "Context [/jaxrsnoap] startup failed due to previous errors: java.lang.IllegalArgumentException: Servlet mapping specifies an unknown servlet name javax.ws.rs.core.Application" > ApplicationInvalid1 is empty subclass of javax.ws.rs.core.Application like: > {code} > public class ApplicationInvalid1 extends Application { > private Set<Class<?>> classes = new HashSet<Class<?>>(); > public ApplicationInvalid1() { > } > @Override > public Set<Class<?>> getClasses() { > return classes; > } > } > {code} > There isn't any reference to this class in web.xml or somewhere else. Only class is placed on classpath. If I remove this class from deployment (= change appropriate line to "war.addClasses(ApplicationTestCase.class);", everything will be OK. -- 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] Created: (AS7-1623) Add security schema v1.1 with the vault element

by Anil Saldhana (JIRA)

Add security schema v1.1 with the vault element ----------------------------------------------- Key: AS7-1623 URL: https://issues.jboss.org/browse/AS7-1623 Project: Application Server 7 Issue Type: Sub-task Components: Security Reporter: Anil Saldhana Assignee: Anil Saldhana Fix For: 7.1.0.Alpha1 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 3 months

3
5
0 / 0

[JBoss JIRA] (AS7-3050) RESTEasy: Boolean configuration parameters don't reject non-sense content

by Weinan Li (Resolved) (JIRA)

[ https://issues.jboss.org/browse/AS7-3050?page=com.atlassian.jira.plugin.s... ] Weinan Li resolved AS7-3050. ---------------------------- Fix Version/s: Open To Community Resolution: Done https://github.com/resteasy/Resteasy/pull/3 > RESTEasy: Boolean configuration parameters don't reject non-sense content > ------------------------------------------------------------------------- > > Key: AS7-3050 > URL: https://issues.jboss.org/browse/AS7-3050 > Project: Application Server 7 > Issue Type: Bug > Components: REST > Affects Versions: 7.1.0.Beta1b > Reporter: Pavel Janousek > Assignee: Weinan Li > Fix For: Open To Community > > > RESTEasy can be configured through several configuration options in WAR application deployment file WEB-INF/web.xml. These options which are type of Boolean (= true, false; maybe we should do support for 0 and 1 too), other invalid or non-sense setting should be rejected as invalid deployment description and a such application should not be deployed at all. > Affected options are: > - resteasy.scan > - resteasy.scan.providers > - resteasy.scan.resources > - resteasy.use.builtin.providers -- 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-2703) clustering task, JPA interceptors should be serializable

by Scott Marlow (Created) (JIRA)

clustering task, JPA interceptors should be serializable -------------------------------------------------------- Key: AS7-2703 URL: https://issues.jboss.org/browse/AS7-2703 Project: Application Server 7 Issue Type: Task Components: Clustering, JPA / Hibernate Reporter: Scott Marlow Assignee: Scott Marlow Fix For: 7.1.0.CR1 -- 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

8
14
0 / 0

[JBoss JIRA] Created: (JBREM-1297) Deadlock between MicroRemoteClientInvoker.establishLease and Client.notifyListeners

by Artur Karpinski (JIRA)

Deadlock between MicroRemoteClientInvoker.establishLease and Client.notifyListeners ----------------------------------------------------------------------------------- Key: JBREM-1297 URL: https://issues.jboss.org/browse/JBREM-1297 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.5.4.SP2 Reporter: Artur Karpinski Priority: Critical Deadlock is probably caused by changes introduced in this fix: JBREM-1242. Thread A: 1. MicroRemoteClientInvoker.terminateLease, locks clientLeaseLock 2. Client.notifyListeners, locks connectionValidatorLock Thread B: 1. Client.setupClientLease, locks connectionValidatorLock 2. MicroRemoteClientInvoker.establishLease, locks connectionValidatorLock Please check stacktraces when this deadlock occurred: {code} "Timer-16" - Thread t@486453 java.lang.Thread.State: BLOCKED at org.jboss.remoting.Client.notifyListeners(Client.java:1873) - waiting to lock <747c39d3> (a java.lang.Object) owned by "WorkManager(2)-241" t@6121 at org.jboss.remoting.LeasePinger.stopPing(LeasePinger.java:134) at org.jboss.remoting.MicroRemoteClientInvoker.terminateLease(MicroRemoteClientInvoker.java:434) - locked <751714e> (a java.lang.Object) at org.jboss.remoting.ConnectionValidator$WaitOnConnectionCheckTimerTask.run(ConnectionValidator.java:1081) at java.util.TimerThread.mainLoop(Timer.java:512) at java.util.TimerThread.run(Timer.java:462) {code} and {code} "WorkManager(2)-241" - Thread t@6121 java.lang.Thread.State: BLOCKED at org.jboss.remoting.MicroRemoteClientInvoker.establishLease(MicroRemoteClientInvoker.java:507) - waiting to lock <751714e> (a java.lang.Object) owned by "Timer-16" t@486453 at org.jboss.remoting.Client.setupClientLease(Client.java:2056) - locked <747c39d3> (a java.lang.Object) at org.jboss.remoting.Client.connect(Client.java:1918) at org.jboss.remoting.Client.connect(Client.java:737) {code} One way to fix this would be to add lock on connectionValidatorLock in MicroRemoteClientInvoker.terminateLease. I'm trying to analyse code to check if this fix will not introduce another deadlock problem. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 3 months

5
11
0 / 0

[JBoss JIRA] Created: (JBWEB-209) CVE Fixes

by Mike Millson (JIRA)

CVE Fixes --------- Key: JBWEB-209 URL: https://issues.jboss.org/browse/JBWEB-209 Project: JBoss Web Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Mike Millson Assignee: Jean-Frederic Clere Provide fixes for the following security issues: CVE-2011-1184 CVE-2011-2204 CVE-2011-2526 CVE-2011-2729 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 3 months

3
5
0 / 0

[JBoss JIRA] (AS7-3175) NPE when using xa datasource with recovery

by Stuart Douglas (Created) (JIRA)

NPE when using xa datasource with recovery ------------------------------------------ Key: AS7-3175 URL: https://issues.jboss.org/browse/AS7-3175 Project: Application Server 7 Issue Type: Bug Components: JCA Affects Versions: 7.1.0.CR1b Reporter: Stuart Douglas Assignee: Jesper Pedersen Fix For: 7.1.0.Final IF you add the <recovery> tag to an XA datasource server startup will fail with an NPE: {code} 07:34:29,840 ERROR [org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$AS7DataSourceDeployer] (MSC service thread 1-10) Error during the deployment of java:jboss/datasources/H2XADS: java.lang.NullPointerException at org.jboss.jca.deployers.common.AbstractDsDeployer.deployXADataSource(AbstractDsDeployer.java:739) at org.jboss.jca.deployers.common.AbstractDsDeployer.createObjectsAndInjectValue(AbstractDsDeployer.java:339) at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$AS7DataSourceDeployer.deploy(AbstractDataSourceService.java:271) at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService.start(AbstractDataSourceService.java:111) at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1824) at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1759) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_29] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_29] at java.lang.Thread.run(Thread.java:680) [:1.6.0_29] {code} The line in question has: {code} if (recoveryMD == null || !recoveryMD.getNoRecovery()) {code} The issue is recoveryMD.getNoRecovery() is returning null. -- 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] (AS7-3170) JMS configuration disappears from configuration xml after being rewritten by JBoss

by Alex Krasov (Created) (JIRA)

JMS configuration disappears from configuration xml after being rewritten by JBoss ---------------------------------------------------------------------------------- Key: AS7-3170 URL: https://issues.jboss.org/browse/AS7-3170 Project: Application Server 7 Issue Type: Bug Components: JMS Affects Versions: 7.1.0.CR1b Environment: Windows7 x64, JBoss AS 7.1.0CR1b Reporter: Alex Krasov Assignee: Clebert Suconic I have 2 JMS queues defined at standalone-full.xml. JBoss recognized them on first run and everything seems to be ok, but it rewrites standalone.xml without queues definition, i.e. completely ommiting the <jms-destinations> element, so after jboss restart queues don't exist anymore. This happens on the first standalone-full.xml rewrite (i.e. after something have been deployed, etc.) This bug is a regression, beta1 and earlier worked just fine. Please see forum thread for detailed discussion, more users' reports and example standalone.xml -- 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

3
2
0 / 0

[JBoss JIRA] (AS7-3162) RESTEasy: Unknown servet name javax.ws.rs.core.Application when javax.ws.rs.core.Application subclass is on classpath

by Stuart Douglas (Commented) (JIRA)

[ https://issues.jboss.org/browse/AS7-3162?page=com.atlassian.jira.plugin.s... ] Stuart Douglas commented on AS7-3162: ------------------------------------- I don't think this is a valid deployment. According to the spec: {code} • If an Application subclass is present that is not being handled by an existing servlet then the servlet added by the ContainerInitializer MUST be named with the fully qualified name of the Application subclass. If the Application subclass is annotated with @ApplicationPath and no servlet-mapping exists for the added servlet then a new servlet mapping is added with the value of the @ApplicationPath annotation with ”/*” appended otherwise the existing mapping is used. If the Application subclass is not annotated with @ApplicationPath then the application MUST be packaged with a web.xml that specifies a servlet mapping for the added servlet. It is an error for more than one application to be deployed at the same effective servlet mapping {code} Basically the presence of an Application class on the CP changes the way that the deployment is handled. I think that we should probably just provide a more meaningful error message in this case. > RESTEasy: Unknown servet name javax.ws.rs.core.Application when javax.ws.rs.core.Application subclass is on classpath > ---------------------------------------------------------------------------------------------------------------------- > > Key: AS7-3162 > URL: https://issues.jboss.org/browse/AS7-3162 > Project: Application Server 7 > Issue Type: Bug > Components: REST > Affects Versions: 7.1.0.CR1b > Reporter: Pavel Janousek > Assignee: Weinan Li > Priority: Blocker > > I've deployment like this: > {code} > @Deployment > public static Archive<?> deploy() { > WebArchive war = ShrinkWrap.create(WebArchive.class, "jaxrsnoap.war"); > war.addPackage(HttpRequest.class.getPackage()); > war.addClasses(ApplicationTestCase.class, ApplicationInvalid1.class); > war.addAsWebInfResource( > WebXml.get("<servlet-mapping>\n" > + " <servlet-name>javax.ws.rs.core.Application</servlet-name>\n" > + " <url-pattern>/myjaxrs/*</url-pattern>\n" > + "</servlet-mapping>\n" + "\n"), "web.xml"); > return war; > } > {code} > This deployment fails during deploying because of "Context [/jaxrsnoap] startup failed due to previous errors: java.lang.IllegalArgumentException: Servlet mapping specifies an unknown servlet name javax.ws.rs.core.Application" > ApplicationInvalid1 is empty subclass of javax.ws.rs.core.Application like: > {code} > public class ApplicationInvalid1 extends Application { > private Set<Class<?>> classes = new HashSet<Class<?>>(); > public ApplicationInvalid1() { > } > @Override > public Set<Class<?>> getClasses() { > return classes; > } > } > {code} > There isn't any reference to this class in web.xml or somewhere else. Only class is placed on classpath. If I remove this class from deployment (= change appropriate line to "war.addClasses(ApplicationTestCase.class);", everything will be OK. -- 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