[JBoss JIRA] (AS7-6234) WAB deployment showing as successful, but not responding
by jarkko rantavuori (JIRA)
jarkko rantavuori created AS7-6234:
--------------------------------------
Summary: WAB deployment showing as successful, but not responding
Key: AS7-6234
URL: https://issues.jboss.org/browse/AS7-6234
Project: Application Server 7
Issue Type: Bug
Components: OSGi
Affects Versions: 7.2.0.Alpha1
Environment: Windows 7
Reporter: jarkko rantavuori
Assignee: Thomas Diesler
Simple Spring WAB file, that I think should work, doesn't seem to. Deployment goes seemingly without issues - no errors are reported - but servlet does not respond to requests. Both OSGi panel and deployment management panel in admin console show the deployment as successful.
Attached server output and .war file, that should respond to /spring-app request.
--
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
[JBoss JIRA] (AS7-6233) System properties referencing each other in domain mode do not work
by Kabir Khan (JIRA)
Kabir Khan created AS7-6233:
-------------------------------
Summary: System properties referencing each other in domain mode do not work
Key: AS7-6233
URL: https://issues.jboss.org/browse/AS7-6233
Project: Application Server 7
Issue Type: Feature Request
Reporter: Kabir Khan
The following set up:
{code}
<system-properties>
<property name="one" value="one1"/>
<property name="two" value="${one}"/>
</system-properties>
{code}
works in standalone, so
{code}
[standalone@localhost:9999 /] :resolve-expression(expression="${two}")
{
"outcome" => "success",
"result" => "one1"
}
{code}
However, in domain mode the properties get passed in in the wrong order so
{code}
[domain@localhost:9999 /] /host=master/server=server-one:resolve-expression(expression="${two}")
{
"outcome" => "success",
"result" => "${one}"
}
{code}
--
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
[JBoss JIRA] (AS7-5958) Incorrect Candidate permutation failed due to a conflict between imports exception when using host and fragment bundles
by Paul Illingworth (JIRA)
[ https://issues.jboss.org/browse/AS7-5958?page=com.atlassian.jira.plugin.s... ]
Paul Illingworth commented on AS7-5958:
---------------------------------------
That's fine. I'll see if I am still having a problem when I take a look at the changes made to help with issue AS7-5951.
> Incorrect Candidate permutation failed due to a conflict between imports exception when using host and fragment bundles
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: AS7-5958
> URL: https://issues.jboss.org/browse/AS7-5958
> Project: Application Server 7
> Issue Type: Bug
> Components: OSGi
> Affects Versions: 7.2.0.Alpha1
> Environment: Windows XP SP3
> Reporter: Paul Illingworth
> Labels: OSGI
>
> I am getting the following exception when my bundle is being resolved. I don't believe this is correct.
> {noformat}
> 2012-11-15 15:10:41,403 DEBUG [org.jboss.osgi.resolver](qtp4105020-187) Candidate permutation failed due to a conflict between imports; will try another if possible.: org.osgi.service.resolver.ResolutionException: Uses constraint violation. Unable to resolve resource resource-console-web [HostBundleRevision[resource-console-web:1.0.0.SNAPSHOT]] because it is exposed to package 'com.google.inject' from resources com.google.inject [HostBundleRevision[com.google.inject:3.0.0]] and com.google.inject [HostBundleRevision[com.google.inject:3.0.0]] via two dependency chains.
> Chain 1:
> resource-console-web [HostBundleRevision[resource-console-web:1.0.0.SNAPSHOT]]
> import: null
> |
> export: osgi.wiring.package=com.google.inject
> com.google.inject [HostBundleRevision[com.google.inject:3.0.0]]
> Chain 2:
> resource-console-web [HostBundleRevision[resource-console-web:1.0.0.SNAPSHOT]]
> import: null
> |
> export: osgi.wiring.package=com.saaconsultants.gwt.rpc.server.servlets; uses:=com.google.inject
> reims-gwt-rpc [HostBundleRevision[reims-gwt-rpc:1.0.0.SNAPSHOT]]
> import: null
> |
> export: osgi.wiring.package=com.google.inject
> com.google.inject [HostBundleRevision[com.google.inject:3.0.0]]
> at org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1142)
> at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:197)
> at org.jboss.osgi.resolver.felix.StatelessResolver.resolve(StatelessResolver.java:56)
> at org.jboss.osgi.framework.internal.ResolverPlugin.resolveAndApply(ResolverPlugin.java:152)
> at org.jboss.osgi.framework.internal.ResolverPlugin.resolveAndApply(ResolverPlugin.java:167)
> at org.jboss.osgi.framework.internal.AbstractBundleState.ensureResolved(AbstractBundleState.java:598)
> at org.jboss.osgi.framework.internal.HostBundleState.startInternal(HostBundleState.java:214)
> at org.jboss.osgi.framework.internal.AbstractBundleState.start(AbstractBundleState.java:520)
> at org.apache.felix.webconsole.internal.core.BundlesServlet.doPost(BundlesServlet.java:331)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:713)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
> at org.apache.felix.webconsole.internal.servlet.OsgiManager.service(OsgiManager.java:437)
> at org.apache.felix.webconsole.internal.servlet.OsgiManager.service(OsgiManager.java:384)
> 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 org.ops4j.pax.web.service.internal.HttpServiceStarted$2.invoke(HttpServiceStarted.java:209)
> at org.ops4j.pax.web.service.internal.$Proxy39.service(Unknown Source)
> at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:547)
> at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:480)
> at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:70)
> at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119)
> at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:520)
> at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:227)
> at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:941)
> at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:117)
> at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:409)
> at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:186)
> at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:875)
> at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
> at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:74)
> at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:110)
> at org.eclipse.jetty.server.Server.handle(Server.java:349)
> at org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:441)
> at org.eclipse.jetty.server.HttpConnection$RequestHandler.content(HttpConnection.java:936)
> at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:801)
> at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:224)
> at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:51)
> at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:586)
> at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:44)
> at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:598)
> at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:533)
> at java.lang.Thread.run(Thread.java:662)
> 2012-11-15 15:10:41,403 TRACE [org.jboss.osgi.framework](qtp4105020-187) Release framework lock
> {noformat}
> It seems to be happening because the ResolverImpl.isCompatible() method is comparing two capabilities; one is an AbstractBundleCapability and the other is a WrappedCapability that contains the same instance of AbstractBundleCapability. The result of the comparison is false.
> As a quick hack I changed the equals method of WrappedCapability to
> {noformat}
> @Override
> public boolean equals(Object obj)
> {
> return m_cap.equals(obj);
> }
> {noformat}
> and that seemed to make it work and resolution was successful.
--
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
[JBoss JIRA] (AS7-5958) Incorrect Candidate permutation failed due to a conflict between imports exception when using host and fragment bundles
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/AS7-5958?page=com.atlassian.jira.plugin.s... ]
Thomas Diesler updated AS7-5958:
--------------------------------
Fix Version/s: (was: 7.2.0.Alpha1)
Assignee: (was: Thomas Diesler)
Ok, we are parking this until we know more.
> Incorrect Candidate permutation failed due to a conflict between imports exception when using host and fragment bundles
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: AS7-5958
> URL: https://issues.jboss.org/browse/AS7-5958
> Project: Application Server 7
> Issue Type: Bug
> Components: OSGi
> Affects Versions: 7.2.0.Alpha1
> Environment: Windows XP SP3
> Reporter: Paul Illingworth
> Labels: OSGI
>
> I am getting the following exception when my bundle is being resolved. I don't believe this is correct.
> {noformat}
> 2012-11-15 15:10:41,403 DEBUG [org.jboss.osgi.resolver](qtp4105020-187) Candidate permutation failed due to a conflict between imports; will try another if possible.: org.osgi.service.resolver.ResolutionException: Uses constraint violation. Unable to resolve resource resource-console-web [HostBundleRevision[resource-console-web:1.0.0.SNAPSHOT]] because it is exposed to package 'com.google.inject' from resources com.google.inject [HostBundleRevision[com.google.inject:3.0.0]] and com.google.inject [HostBundleRevision[com.google.inject:3.0.0]] via two dependency chains.
> Chain 1:
> resource-console-web [HostBundleRevision[resource-console-web:1.0.0.SNAPSHOT]]
> import: null
> |
> export: osgi.wiring.package=com.google.inject
> com.google.inject [HostBundleRevision[com.google.inject:3.0.0]]
> Chain 2:
> resource-console-web [HostBundleRevision[resource-console-web:1.0.0.SNAPSHOT]]
> import: null
> |
> export: osgi.wiring.package=com.saaconsultants.gwt.rpc.server.servlets; uses:=com.google.inject
> reims-gwt-rpc [HostBundleRevision[reims-gwt-rpc:1.0.0.SNAPSHOT]]
> import: null
> |
> export: osgi.wiring.package=com.google.inject
> com.google.inject [HostBundleRevision[com.google.inject:3.0.0]]
> at org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1142)
> at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:197)
> at org.jboss.osgi.resolver.felix.StatelessResolver.resolve(StatelessResolver.java:56)
> at org.jboss.osgi.framework.internal.ResolverPlugin.resolveAndApply(ResolverPlugin.java:152)
> at org.jboss.osgi.framework.internal.ResolverPlugin.resolveAndApply(ResolverPlugin.java:167)
> at org.jboss.osgi.framework.internal.AbstractBundleState.ensureResolved(AbstractBundleState.java:598)
> at org.jboss.osgi.framework.internal.HostBundleState.startInternal(HostBundleState.java:214)
> at org.jboss.osgi.framework.internal.AbstractBundleState.start(AbstractBundleState.java:520)
> at org.apache.felix.webconsole.internal.core.BundlesServlet.doPost(BundlesServlet.java:331)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:713)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
> at org.apache.felix.webconsole.internal.servlet.OsgiManager.service(OsgiManager.java:437)
> at org.apache.felix.webconsole.internal.servlet.OsgiManager.service(OsgiManager.java:384)
> 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 org.ops4j.pax.web.service.internal.HttpServiceStarted$2.invoke(HttpServiceStarted.java:209)
> at org.ops4j.pax.web.service.internal.$Proxy39.service(Unknown Source)
> at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:547)
> at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:480)
> at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:70)
> at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119)
> at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:520)
> at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:227)
> at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:941)
> at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:117)
> at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:409)
> at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:186)
> at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:875)
> at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
> at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:74)
> at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:110)
> at org.eclipse.jetty.server.Server.handle(Server.java:349)
> at org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:441)
> at org.eclipse.jetty.server.HttpConnection$RequestHandler.content(HttpConnection.java:936)
> at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:801)
> at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:224)
> at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:51)
> at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:586)
> at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:44)
> at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:598)
> at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:533)
> at java.lang.Thread.run(Thread.java:662)
> 2012-11-15 15:10:41,403 TRACE [org.jboss.osgi.framework](qtp4105020-187) Release framework lock
> {noformat}
> It seems to be happening because the ResolverImpl.isCompatible() method is comparing two capabilities; one is an AbstractBundleCapability and the other is a WrappedCapability that contains the same instance of AbstractBundleCapability. The result of the comparison is false.
> As a quick hack I changed the equals method of WrappedCapability to
> {noformat}
> @Override
> public boolean equals(Object obj)
> {
> return m_cap.equals(obj);
> }
> {noformat}
> and that seemed to make it work and resolution was successful.
--
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
[JBoss JIRA] (AS7-6232) DefaultAuthenticationCacheFactory should not use internal Infinispan classes
by Tristan Tarrant (JIRA)
Tristan Tarrant created AS7-6232:
------------------------------------
Summary: DefaultAuthenticationCacheFactory should not use internal Infinispan classes
Key: AS7-6232
URL: https://issues.jboss.org/browse/AS7-6232
Project: Application Server 7
Issue Type: Bug
Components: Security
Affects Versions: 7.1.3.Final (EAP)
Reporter: Tristan Tarrant
Assignee: Anil Saldhana
The DefaultAuthenticationCacheFactory class (and the AuthenticationCacheEvictionListener class) use internal Infinispan classes which are subject to change without API stability guarantees. The code should be rewritten to use an Infinispan cache instead.
--
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
[JBoss JIRA] (AS7-5951) Cannot reliably deploy OSGi host and fragment bundles on server restart
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/AS7-5951?page=com.atlassian.jira.plugin.s... ]
Thomas Diesler edited comment on AS7-5951 at 12/20/12 8:02 AM:
---------------------------------------------------------------
I think we need more data here.
I updated the framework and bootstrap integration code to produce better logging. You should now see something like this
{code}
[tdiesler@tdmac jboss-as-7.2.0.Alpha1-SNAPSHOT]$ cat standalone/log/server.log | grep "on behalf of"
17:00:43,353 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-3) Install bootstrap deployments [[org.apache.felix.log:1.0.0,location=org.apache.felix.log], [jboss-osgi-logging:1.0.0,location=org.jboss.osgi.logging], [org.apache.felix.configadmin:1.2.8,location=org.apache.felix.configadmin], [jboss-as-osgi-configadmin:7.2.0.Alpha1-SNAPSHOT,location=org.jboss.as.osgi.configadmin]] on behalf of jbosgi.BootstrapBundles.INSTALL
17:00:43,379 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-3) Resolve bootstrap bundles on behalf of jbosgi.BootstrapBundles.RESOLVE
17:00:43,481 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-3) Activate bootstrap bundles on behalf of jbosgi.BootstrapBundles.ACTIVATE
17:00:43,487 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-7) Complete bootstrap bundles on behalf of jbosgi.BootstrapBundles.COMPLETE
17:00:43,502 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-7) Install persistent deployments [] on behalf of jbosgi.PersistentBundles.INSTALL
17:00:43,503 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-7) Resolve persistent bundles on behalf of jbosgi.PersistentBundles.RESOLVE
17:00:43,503 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-7) Activate persistent bundles on behalf of jbosgi.PersistentBundles.ACTIVATE
17:00:43,504 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-8) Complete persistent bundles on behalf of jbosgi.PersistentBundles.COMPLETE
{code}
The idea is that the persistent bundles get installed only after the bootstrap bundles (i.e. the configured capabilities) complete. Also, no persistent bundle should resolve before not all persistent bundles are installed. Could you please verify you output according to these rules.
For a fragment that does not attach, we need to find out why it is not included in the resolve attempt. If it is included, it might be a resolver issue.
The related code change is here: https://github.com/jbossas/jboss-as/pull/3727
was (Author: thomas.diesler):
I think we need more data here.
I updated the framework and bootstrap integration code to produce better logging. You should now see something like this
{code}
[tdiesler@tdmac jboss-as-7.2.0.Alpha1-SNAPSHOT]$ cat standalone/log/server.log | grep "on behalf of"
17:00:43,353 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-3) Install bootstrap deployments [[org.apache.felix.log:1.0.0,location=org.apache.felix.log], [jboss-osgi-logging:1.0.0,location=org.jboss.osgi.logging], [org.apache.felix.configadmin:1.2.8,location=org.apache.felix.configadmin], [jboss-as-osgi-configadmin:7.2.0.Alpha1-SNAPSHOT,location=org.jboss.as.osgi.configadmin]] on behalf of jbosgi.BootstrapBundles.INSTALL
17:00:43,379 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-3) Resolve bootstrap bundles on behalf of jbosgi.BootstrapBundles.RESOLVE
17:00:43,481 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-3) Activate bootstrap bundles on behalf of jbosgi.BootstrapBundles.ACTIVATE
17:00:43,487 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-7) Complete bootstrap bundles on behalf of jbosgi.BootstrapBundles.COMPLETE
17:00:43,502 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-7) Install persistent deployments [] on behalf of jbosgi.PersistentBundles.INSTALL
17:00:43,503 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-7) Resolve persistent bundles on behalf of jbosgi.PersistentBundles.RESOLVE
17:00:43,503 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-7) Activate persistent bundles on behalf of jbosgi.PersistentBundles.ACTIVATE
17:00:43,504 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-8) Complete persistent bundles on behalf of jbosgi.PersistentBundles.COMPLETE
{code}
The idea is that the persistent bundles get installed only after the bootstrap bundles (i.e. the configured capabilities) complete. Also, no persistent bundle should resolve before not all persistent bundles are installed. Could you please verify you output according to these rules.
For a fragment that does not attach, we need to find out why it is not included in the resolve attempt. If it is included, it might be a resolver issue.
The related code change is [here|https://github.com/jbossas/jboss-as/pull/3713]
> Cannot reliably deploy OSGi host and fragment bundles on server restart
> -----------------------------------------------------------------------
>
> Key: AS7-5951
> URL: https://issues.jboss.org/browse/AS7-5951
> Project: Application Server 7
> Issue Type: Bug
> Components: OSGi
> Affects Versions: 7.2.0.Alpha1
> Environment: Windows XP SP3
> Reporter: Paul Illingworth
> Assignee: Thomas Diesler
> Labels: OSGI
> Fix For: 7.2.0.Alpha1
>
> Attachments: this_one_failed.txt, this_one_worked.txt
>
>
> If I deploy guice-3.0.0 (host bundle), guice-servlet (fragment) and guice-persist (fragment) into the "deployments" folder then the there is no guarantee the fragments will be installed before the host and so they may not be attached to the host when it resolves.
> This happens on starting the application server. Sometimes the fragments are attached, sometimes they aren't.
> If I install the bundles into the "bundles" folder structure and add capability entries to the standalone.xml file then it works as expected.
> I am using 7.2.0-Alpha1 built from cb72a7cd1669131b28a552f1dbf3c2582ad19813.
--
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
[JBoss JIRA] (AS7-6231) Context initialization exceptions are swallowed on deployment
by jarkko rantavuori (JIRA)
[ https://issues.jboss.org/browse/AS7-6231?page=com.atlassian.jira.plugin.s... ]
jarkko rantavuori commented on AS7-6231:
----------------------------------------
Added. Should be self-contained: just a spring app with one controller and one bean, saying hello world.
> Context initialization exceptions are swallowed on deployment
> -------------------------------------------------------------
>
> Key: AS7-6231
> URL: https://issues.jboss.org/browse/AS7-6231
> Project: Application Server 7
> Issue Type: Bug
> Components: EE
> Affects Versions: 7.2.0.Alpha1
> Environment: Windows 7
> Reporter: jarkko rantavuori
> Assignee: David Lloyd
> Attachments: jboss-7.1.1.-stacktrace-beans.txt, jboss-7.1.1.-stacktrace-namespace.txt, jboss-7.2.0.-stacktrace-namespace.txt, spring-app-1.0.0-BUILD-SNAPSHOT-startupexception.war
>
>
> On 7.2.0.Alpha1, trying to deploy a simple spring app with problems in context initialization, all exceptions are swallowed, and only a meaningless error
> org.jboss.msc.service.StartException in anonymous service: JBAS018040: Failed to start context at org.jboss.as.web.deployment.WebDeploymentService.doStart(WebDeploymentService.java:161)
> is shown, making it impossible to find out the root cause.
> On 7.1.1., meaningful exception is shown, like
> Configuration problem: Unable to locate Spring NamespaceHandler for XML schema namespace [http://www.osgi.org/xmlns/blueprint/v1.0.0]
> Offending resource: ServletContext resource [/WEB-INF/spring/root-context.xml]
> or
> org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException
> Caused by: org.xml.sax.SAXParseException; lineNumber: 6; columnNumber: 108; cvc-elt.1: Cannot find the declaration of element 'beans'.
> which allows the developer to fix 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
[JBoss JIRA] (AS7-6231) Context initialization exceptions are swallowed on deployment
by jarkko rantavuori (JIRA)
[ https://issues.jboss.org/browse/AS7-6231?page=com.atlassian.jira.plugin.s... ]
jarkko rantavuori updated AS7-6231:
-----------------------------------
Attachment: spring-app-1.0.0-BUILD-SNAPSHOT-startupexception.war
> Context initialization exceptions are swallowed on deployment
> -------------------------------------------------------------
>
> Key: AS7-6231
> URL: https://issues.jboss.org/browse/AS7-6231
> Project: Application Server 7
> Issue Type: Bug
> Components: EE
> Affects Versions: 7.2.0.Alpha1
> Environment: Windows 7
> Reporter: jarkko rantavuori
> Assignee: David Lloyd
> Attachments: jboss-7.1.1.-stacktrace-beans.txt, jboss-7.1.1.-stacktrace-namespace.txt, jboss-7.2.0.-stacktrace-namespace.txt, spring-app-1.0.0-BUILD-SNAPSHOT-startupexception.war
>
>
> On 7.2.0.Alpha1, trying to deploy a simple spring app with problems in context initialization, all exceptions are swallowed, and only a meaningless error
> org.jboss.msc.service.StartException in anonymous service: JBAS018040: Failed to start context at org.jboss.as.web.deployment.WebDeploymentService.doStart(WebDeploymentService.java:161)
> is shown, making it impossible to find out the root cause.
> On 7.1.1., meaningful exception is shown, like
> Configuration problem: Unable to locate Spring NamespaceHandler for XML schema namespace [http://www.osgi.org/xmlns/blueprint/v1.0.0]
> Offending resource: ServletContext resource [/WEB-INF/spring/root-context.xml]
> or
> org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException
> Caused by: org.xml.sax.SAXParseException; lineNumber: 6; columnNumber: 108; cvc-elt.1: Cannot find the declaration of element 'beans'.
> which allows the developer to fix 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