[JBoss JIRA] Created: (AS7-1974) Unable to access OSGI service (BundleContext) from WebApp (servlet / RestEasy) using AS 7.1.1 stack.
by Nikhil Joshi (JIRA)
Unable to access OSGI service (BundleContext) from WebApp (servlet / RestEasy) using AS 7.1.1 stack.
----------------------------------------------------------------------------------------------------
Key: AS7-1974
URL: https://issues.jboss.org/browse/AS7-1974
Project: Application Server 7
Issue Type: Clarification
Components: OSGi
Affects Versions: 7.1.0.Alpha1
Environment: Using JBoss Developer Studio M3 on Windows 7. Server AS 7.0.0 final, 7.1.1 Alpha, EAP 6.0 (experimental)
Reporter: Nikhil Joshi
Assignee: Thomas Diesler
This is with reference to thread on community forum
http://community.jboss.org/thread/172622
I am trying to access a OSGI Bundle from a Web Application. Where getting following error.
12:16:04,070 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/MyRestService].[SimpleClientServlet]] (http--127.0.0.1-8080-1) Allocate exception for servlet SimpleClientServlet: java.lang.IllegalArgumentException: Can not set org.osgi.framework.BundleContext field sample.SimpleClientServlet.context to org.jboss.osgi.framework.internal.SystemBundleContext
at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(Unknown Source) [:1.6.0_25]
at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(Unknown Source) [:1.6.0_25]
at sun.reflect.UnsafeObjectFieldAccessorImpl.set(Unknown Source) [:1.6.0_25]
at java.lang.reflect.Field.set(Unknown Source) [:1.6.0_25]
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (AS7-2068) Cannot use other JMS provider deployed as resource adapter (RAR)
by Robert Stupp (Created) (JIRA)
Cannot use other JMS provider deployed as resource adapter (RAR)
----------------------------------------------------------------
Key: AS7-2068
URL: https://issues.jboss.org/browse/AS7-2068
Project: Application Server 7
Issue Type: Bug
Components: EJB
Affects Versions: 7.0.2.Final
Reporter: Robert Stupp
Assignee: Carlo de Wolf
I've configured JBoss AS 7.0.1.Final without messaging subsystem.
A resource adapter (sonicmq-jms-ra.rar) has been successfully deployed to JBoss - JNDI references exists.
{noformat}
[org.jboss.as.server.deployment] (MSC service thread 1-1) Starting deployment of "sonicmq-jms-ra.rar"
[org.jboss.as.connector.metadata.deployment.ResourceAdapterXmlDeploymentService$AS7RaXmlDeployer] (MSC service thread 1-1) Registered connection factory java:/ConnectionFactory
[org.jboss.as.connector.metadata.deployment.ResourceAdapterXmlDeploymentService$AS7RaXmlDeployer] (MSC service thread 1-1) IJ020002: Deployed: file:/E:/jboss/jboss-as-7.0.2.Final/standalone/tmp/vfs/tempffbd2948ba3869df/sonicmq-jms-ra.rar-14d86ac7606f92a7/contents/
[org.jboss.as.deployment.connector] (MSC service thread 1-1) Starting sevice service jboss.ra.sonicmq-jms-ra_1
{noformat}
But it is not possible to use that JMS-RA for MessageDrivenBeans.
I tried to add
{noformat}
<subsystem xmlns="urn:jboss:domain:ejb3:1.1" lite="false">
<mdb>
<resource-adapter-ref resource-adapter-name="sonicmq-jms-ra"/>
</mdb>
{noformat}
and
{noformat}
<subsystem xmlns="urn:jboss:domain:ejb3:1.1" lite="false">
<mdb>
<resource-adapter-ref resource-adapter-name="deployment.sonicmq-jms-ra"/>
</mdb>
{noformat}
Both fail with either
{noformat}
ServiceNotFoundException: Service service sonicmq-jms-ra not found
{noformat}
or
{noformat}
IllegalStateException: No resource adapter registered with resource adapter name deployment.sonicmq-jms-ra
{noformat}
I tried to figure out how hornetq-ra is added as a resource adapter to JBoss 7 (wanted to add sonicmq-jms-ra as a subsystem/service) - but there's no documentation how to do that.
It would be nice to have a solution/workaround quickly - because my evalutation copy will expire in a few days.
--
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, 6 months
[JBoss JIRA] Created: (AS7-1607) Investigate: can we move logging dependencies out of property org.jboss.osgi.system.modules?
by David Bosschaert (JIRA)
Investigate: can we move logging dependencies out of property org.jboss.osgi.system.modules?
--------------------------------------------------------------------------------------------
Key: AS7-1607
URL: https://issues.jboss.org/browse/AS7-1607
Project: Application Server 7
Issue Type: Task
Components: OSGi
Affects Versions: 7.0.1.Final, 7.0.0.Final
Reporter: David Bosschaert
Assignee: David Bosschaert
Priority: Minor
Currently the org.jboss.osgi.system.modules property contains a number of logging components:
{code:xml}<property name="org.jboss.osgi.system.modules">
org.apache.commons.logging,
org.apache.log4j,
org.jboss.as.osgi,
org.slf4j,
</property>{code}
It would be good to see if we can move these modules to the <modules> section of the configuration and load them as proper modules rather than having them merged with the system module.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (JGRP-188) JGroups should not use System properties, because it's too restrictive
by Julien Kronegg (Commented) (JIRA)
[ https://issues.jboss.org/browse/JGRP-188?page=com.atlassian.jira.plugin.s... ]
Julien Kronegg commented on JGRP-188:
-------------------------------------
I think this issue should be reopened because using configuration parameters set through System properties may lead to security issues.
Imagine that encryption parameters store password and key password are set via System properties such as:
{code}
<ENCRYPT store_password="${systemPropertyStorePassword:changeit}" store_password="${systemPropertyKeyPassword:changeit}"/>
{code}
This may lead to security issues if the system properties may be read remotely. This occurs e.g. via MBeans:
- IBM's ITCAM OSInfo
- JBoss AS's System Properties Service (http://docs.jboss.org/jbossas/jboss4guide/r1/html/ch10.html)
The information disclosure is limited since the passwords are only used to unlock the keystore (they could not be used to decrypt the data).
> JGroups should not use System properties, because it's too restrictive
> ----------------------------------------------------------------------
>
> Key: JGRP-188
> URL: https://issues.jboss.org/browse/JGRP-188
> Project: JGroups
> Issue Type: Feature Request
> Affects Versions: 2.2.8, 2.2.9, 2.2.9.1
> Environment: all
> Reporter: Robert Stevenson
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 2.4
>
> Original Estimate: 1 day
> Remaining Estimate: 1 day
>
> JGroups should not use System properties for configuration, it should instead use a Global Configurator class (singleton), similar to log4j; which just contains a Properties object. This would allow JGroups to be much easier to move around to different environments. For example : (Applet), which does not have access to easily change System properties, on a per applet basis.
> This new class could have a mapping/conversion method to make the current -D command line options be put into this new Properties Configurator for backward compatibility
--
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, 6 months
[JBoss JIRA] (AS7-2049) Failures in ConfigurationAdminTestCase
by Stuart Douglas (Created) (JIRA)
Failures in ConfigurationAdminTestCase
---------------------------------------
Key: AS7-2049
URL: https://issues.jboss.org/browse/AS7-2049
Project: Application Server 7
Issue Type: Bug
Components: OSGi
Affects Versions: 7.1.0.Alpha1
Reporter: Stuart Douglas
Assignee: Thomas Diesler
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.53 sec <<< FAILURE!
testManagedService(org.jboss.as.testsuite.integration.osgi.configadmin.ConfigurationAdminTestCase) Time elapsed: 0.078 sec <<< ERROR!
java.lang.ClassCastException: java.lang.Boolean cannot be cast to java.lang.String
at org.jboss.as.osgi.service.ConfigAdminServiceImpl.putConfiguration(ConfigAdminServiceImpl.java:158)
at org.jboss.as.osgi.configadmin.DomainModelPersistenceManager.store(DomainModelPersistenceManager.java:98)
at org.apache.felix.cm.impl.CachingPersistenceManagerProxy.store(CachingPersistenceManagerProxy.java:173)
at org.apache.felix.cm.impl.ConfigurationImpl.<init>(ConfigurationImpl.java:195)
at org.apache.felix.cm.impl.ConfigurationManager.createConfiguration(ConfigurationManager.java:751)
at org.apache.felix.cm.impl.ConfigurationManager.getConfiguration(ConfigurationManager.java:492)
at org.apache.felix.cm.impl.ConfigurationAdminImpl.getConfiguration(ConfigurationAdminImpl.java:93)
at org.jboss.as.testsuite.integration.osgi.configadmin.ConfigurationAdminTestCase.testManagedService(ConfigurationAdminTestCase.java:115)
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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
at org.jboss.arquillian.junit.Arquillian$6$1.invoke(Arquillian.java:246)
at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60)
at sun.reflect.GeneratedMethodAccessor17.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:134)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:114)
at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
at org.jboss.arquillian.container.test.impl.execution.ContainerTestExecuter.execute(ContainerTestExecuter.java:38)
at sun.reflect.GeneratedMethodAccessor16.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:82)
at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:68)
at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:54)
at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:134)
at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:111)
at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:239)
at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:202)
at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:290)
at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:45)
at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:216)
at org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(BlockJUnit4ClassRunner.java:79)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:71)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:49)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:161)
at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:290)
at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:45)
at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:175)
at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:123)
at org.junit.runner.JUnitCore.run(JUnitCore.java:157)
at org.junit.runner.JUnitCore.run(JUnitCore.java:136)
at org.jboss.arquillian.junit.container.JUnitTestRunner.execute(JUnitTestRunner.java:65)
at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethodInternal(JMXTestRunner.java:128)
at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethod(JMXTestRunner.java:107)
at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.runTestMethod(ArquillianService.java:227)
at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:93)
at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:27)
at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:208)
at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:120)
at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:262)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:836)
at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:761)
at org.jboss.as.jmx.tcl.TcclMBeanServer.invoke(TcclMBeanServer.java:218)
at org.jboss.as.jmx.model.ModelControllerMBeanServer.invoke(ModelControllerMBeanServer.java:202)
at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1427)
at javax.management.remote.rmi.RMIConnectionImpl.access$200(RMIConnectionImpl.java:72)
at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1265)
at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1360)
at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:788)
at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305)
at sun.rmi.transport.Transport$1.run(Transport.java:159)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:155)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:680)
--
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, 7 months
[JBoss JIRA] (AS7-1888) IllegalStateException when deploying & starting a bundle through web console
by David Bosschaert (Resolved) (JIRA)
[ https://issues.jboss.org/browse/AS7-1888?page=com.atlassian.jira.plugin.s... ]
David Bosschaert resolved AS7-1888.
-----------------------------------
Resolution: Cannot Reproduce Bug
Following the same steps as before, I am not able to reproduce this problem any more.
> IllegalStateException when deploying & starting a bundle through web console
> ----------------------------------------------------------------------------
>
> Key: AS7-1888
> URL: https://issues.jboss.org/browse/AS7-1888
> Project: Application Server 7
> Issue Type: Bug
> Components: OSGi
> Reporter: David Bosschaert
> Assignee: David Bosschaert
> Fix For: 7.1.0.Beta1
>
>
> When installing a bundle through the web console and ticking the start tickbox as well, it often generates an exception (see below). It is probably related to the fact that if you don't select the start tickbox, the bundle gets started anyway. With the tickbox enabled it seems like the system is trying to start the bundle twice concurrently.
> org.apache.felix.log.LogException: org.osgi.framework.BundleException: Cannot start bundle: exporting-bundle:0.0.0
> at org.jboss.osgi.container.bundle.HostBundle.startInternal(HostBundle.java:239)
> at org.jboss.osgi.container.bundle.AbstractBundle.start(AbstractBundle.java:478)
> at org.jboss.osgi.container.plugin.internal.StartLevelPluginImpl$3.run(StartLevelPluginImpl.java:162)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:619)
> Caused by: java.lang.IllegalStateException: BundleContext already available
> at org.jboss.osgi.container.bundle.AbstractBundle.createBundleContext(AbstractBundle.java:170)
> at org.jboss.osgi.container.bundle.HostBundle.startInternal(HostBundle.java:179)
> ... 5 more
--
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, 7 months