[JBoss JIRA] (AS7-6234) WAB deployment showing as successful, but not responding
by jarkko rantavuori (JIRA)
[ https://issues.jboss.org/browse/AS7-6234?page=com.atlassian.jira.plugin.s... ]
jarkko rantavuori updated AS7-6234:
-----------------------------------
Attachment: spring-app-source-codes.zip
> 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
> Attachments: jboss-7.2.0-server-output-deployment-showing-as-successful.txt, spring-app-1.0.0-BUILD-SNAPSHOT-looks-to-start-normally-but-doesnt.war, spring-app-source-codes.zip
>
>
> 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
13 years, 4 months
[JBoss JIRA] (AS7-6219) Whitespace on Bundle-Classpath manifest header should not fail WAB deployment
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/AS7-6219?page=com.atlassian.jira.plugin.s... ]
Thomas Diesler updated AS7-6219:
--------------------------------
Issue Type: Bug (was: Enhancement)
> Whitespace on Bundle-Classpath manifest header should not fail WAB deployment
> -----------------------------------------------------------------------------
>
> Key: AS7-6219
> URL: https://issues.jboss.org/browse/AS7-6219
> Project: Application Server 7
> Issue Type: Bug
> Components: OSGi
> Affects Versions: 7.2.0.Alpha1
> Environment: Windows 7
> Reporter: jarkko rantavuori
> Assignee: Thomas Diesler
> Fix For: 7.2.0.Alpha1
>
> Attachments: bundle-classpath.txt
>
>
> Indentation of values works for Import-Package header, but if used with Bundle-Classpath header, it doesn't work and classes are not found. See attachment for details.
> This can lead to subtle, hard-to-analyze failures in the deployment. Manifest is often configured in maven pom, where indentation is common.
--
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
13 years, 4 months
[JBoss JIRA] (AS7-5951) Cannot reliably deploy OSGi host and fragment bundles on server restart
by Paul Illingworth (JIRA)
[ https://issues.jboss.org/browse/AS7-5951?page=com.atlassian.jira.plugin.s... ]
Paul Illingworth commented on AS7-5951:
---------------------------------------
I'll give this a go as soon as I can. It'll probably early next year I'm afraid.
(I am currently avoiding the problem by using a single bundle that combines all the guice host and fragment bundles)
> 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
13 years, 4 months
[JBoss JIRA] (AS7-6235) Reconsider expressions for model reference attributes in server-group and server-config
by Brian Stansberry (JIRA)
Brian Stansberry created AS7-6235:
-------------------------------------
Summary: Reconsider expressions for model reference attributes in server-group and server-config
Key: AS7-6235
URL: https://issues.jboss.org/browse/AS7-6235
Project: Application Server 7
Issue Type: Sub-task
Components: Domain Management
Reporter: Brian Stansberry
Priority: Critical
Fix For: 7.2.0.Alpha1
There are some attributes in the server-group and server-config resources that represent references to other resources that support expressions. For example the "group" attribute in a server-config and the "profile" attribute in a server-group. Supporting expressions on such attributes is problematic because it precludes accurately validating that the reference is valid during operation execution Stage.MODEL. This is because expression resolution sources may not be fully populated until Stage.RUNTIME.
I wanted to remove expression support from these attributes but was unwilling to do so because of concerns about breaking compatibility. But some recent testing showed me that on *master* for at least some of these, setting an expression would not work -- the HC could not launch servers. If these expressions didn't work *in previous releases* as well, we can remove support for them without breaking compatibility.
The task here is to test setting these attributes to expressions in 7.1.2 and 7.1.3. For any attribute like this where expression support didn't actually work, we should remove the support in 7.2.
Testing can be done by simply taking the current xml attribute value, e.g. "foo" and using it as the default in an expression, e.g. "${exp-test:foo}" and then starting the HC. There is no need to mess with setting system property "exp-test".
--
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
13 years, 4 months
[JBoss JIRA] (AS7-6234) WAB deployment showing as successful, but not responding
by jarkko rantavuori (JIRA)
[ https://issues.jboss.org/browse/AS7-6234?page=com.atlassian.jira.plugin.s... ]
jarkko rantavuori updated AS7-6234:
-----------------------------------
Attachment: jboss-7.2.0-server-output-deployment-showing-as-successful.txt
spring-app-1.0.0-BUILD-SNAPSHOT-looks-to-start-normally-but-doesnt.war
> 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
> Attachments: jboss-7.2.0-server-output-deployment-showing-as-successful.txt, spring-app-1.0.0-BUILD-SNAPSHOT-looks-to-start-normally-but-doesnt.war
>
>
> 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
13 years, 4 months
[JBoss JIRA] (JBRULES-3693) Pull Request to update smooks to 1.5.1
by Nick Cross (JIRA)
[ https://issues.jboss.org/browse/JBRULES-3693?page=com.atlassian.jira.plug... ]
Nick Cross updated JBRULES-3693:
--------------------------------
Fix Version/s: 6.0.0.Alpha1
> Pull Request to update smooks to 1.5.1
> --------------------------------------
>
> Key: JBRULES-3693
> URL: https://issues.jboss.org/browse/JBRULES-3693
> Project: JBRULES
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Affects Versions: 6.0.0.Alpha1
> Reporter: George Varsamis
> Assignee: Mark Proctor
> Fix For: 6.0.0.Alpha1
>
>
> Switchyard requires Smooks v 1.5.1 . I have updated drools parent to use smooks 1.5.1 and also updated the source code in droolsjbpm-integration/drools-pipeline to reflect this. The change is trivial. I have run the tests and the change had no adverse effect on the codebase.
> I will attach the pull requests to this ticket.
--
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
13 years, 4 months
[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
13 years, 4 months
[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
13 years, 4 months
[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
13 years, 4 months