[JBoss JIRA] Created: (AS7-1288) NPE in thread "vfs-shutdown"
by Juergen Zimmermann (JIRA)
NPE in thread "vfs-shutdown"
-----------------------------
Key: AS7-1288
URL: https://issues.jboss.org/browse/AS7-1288
Project: Application Server 7
Issue Type: Bug
Components: VFS
Affects Versions: 7.0.0.Final
Environment: 7.1.0.Alpha1 Jenkins build 1402
Reporter: Juergen Zimmermann
Assignee: John Bailey
When I shutdown a standalone server I'm getting a NPE. The shutdown command is:
jboss-admin.bat --connect command=:shutdown
Console log:
...
18:24:55,990 INFO [org.jboss.as.logging] Restored bootstrap log handlers
18:24:55,990 INFO [org.jboss.as.jmx.JMXConnectorService] JMX remote connector stopped
18:24:56,075 INFO [org.jboss.osgi.framework.internal.HostBundleState] Bundle stopped: jboss-as-osgi-configadmin:7.1.0.Alpha1-SNAPSHOT
18:24:56,125 INFO [org.jboss.osgi.framework.internal.HostBundleState] Bundle stopped: org.apache.felix.log:1.0.0
18:24:56,230 INFO [org.apache.catalina.core.StandardContext] Container org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/] has not been started
18:24:56,286 INFO [org.jboss.osgi.framework.internal.HostBundleState] Bundle stopped: org.apache.felix.configadmin:1.2.8
18:24:56,323 INFO [org.jboss.osgi.framework.internal.HostBundleState] Bundle stopped: jboss-osgi-logging:1.0.0
18:24:56,330 INFO [com.arjuna.ats.jbossatx] ARJUNA32018: Destroying TransactionManagerService
18:24:56,331 INFO [com.arjuna.ats.jbossatx] ARJUNA32014: Stopping transaction recovery manager
18:24:56,368 ERROR [stderr] Exception in thread "vfs-shutdown" java.lang.NullPointerException
18:24:56,368 ERROR [stderr] at org.jboss.vfs.TempFileProvider$DeleteTask.run(TempFileProvider.java:151)
18:24:56,368 ERROR [stderr] at org.jboss.vfs.TempFileProvider.close(TempFileProvider.java:132)
18:24:56,368 ERROR [stderr] at org.jboss.osgi.vfs30.VirtualFileAdaptor30$2.run(VirtualFileAdaptor30.java:94)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 9 months
[JBoss JIRA] (JBMESSAGING-1930) org.jboss.jms.server.container.SecurityAspect.check is missing privileged blocks
by Yong Hao Gao (JIRA)
[ https://issues.jboss.org/browse/JBMESSAGING-1930?page=com.atlassian.jira.... ]
Yong Hao Gao closed JBMESSAGING-1930.
-------------------------------------
Resolution: Done
> org.jboss.jms.server.container.SecurityAspect.check is missing privileged blocks
> --------------------------------------------------------------------------------
>
> Key: JBMESSAGING-1930
> URL: https://issues.jboss.org/browse/JBMESSAGING-1930
> Project: JBoss Messaging
> Issue Type: Bug
> Components: JMS Security
> Affects Versions: 1.4.8.SP5
> Reporter: Derek Horton
> Assignee: Yong Hao Gao
> Fix For: 1.4.8.SP8
>
> Attachments: JBPAPP-7335.patch
>
>
> A customer is trying to use the Java security manager on EAP 5.0.1. When the security manager is enabled, JBoss is throwing the following exception when they deploy their application that uses JMS:
> Caused by: java.security.AccessControlException: access denied (javax.management.MBeanPermission org.jboss.jms.server.jbosssx.JBossASSecurityMetadataStore#getSecurityMetadata[jboss.messaging:service=SecurityStore] invoke)
> at java.security.AccessControlContext.checkPermission(AccessControlContext.java:323)
> at java.security.AccessController.checkPermission(AccessController.java:546)
> at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
> at org.jboss.system.security.DebuggingJavaSecurityManager.checkPermission(DebuggingJavaSecurityManager.java:95)
> at org.jboss.mx.server.MBeanServerImpl.checkMBeanPermission(MBeanServerImpl.java:1735)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:663)
> at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> at $Proxy85.getSecurityMetadata(Unknown Source)
> at org.jboss.jms.server.container.SecurityAspect.check(SecurityAspect.java:285)
> at org.jboss.jms.server.container.SecurityAspect.handleCreateConsumerDelegate(SecurityAspect.java:113)
> 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.jboss.aop.advice.PerInstanceAdvice.invoke(PerInstanceAdvice.java:122)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> at org.jboss.jms.server.container.ServerLogInterceptor.invoke(ServerLogInterceptor.java:105)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> at org.jboss.jms.server.endpoint.advised.SessionAdvised.createConsumerDelegate(SessionAdvised.java)
> at org.jboss.jms.wireformat.SessionCreateConsumerDelegateRequest.serverInvoke(SessionCreateConsumerDelegateRequest.java:100)
> at org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSServerInvocationHandler.java:157)
> at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:930)
> at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
> at org.jboss.remoting.Client.invoke(Client.java:2034)
> at org.jboss.remoting.Client.invoke(Client.java:877)
> at org.jboss.remoting.Client.invoke(Client.java:865)
> at org.jboss.jms.client.delegate.DelegateSupport.doInvoke(DelegateSupport.java:189)
> I found a JIRA [1] that appears to resolve the issue in messaging versions 1.4.0.SP3.CP05, 1.4.1.GA, 1.4.2.GA. I tried adding the following grant statement to the java security policy file, hoping that would resolve the issue.
>
> grant codeBase "file:${jboss.home.dir}/common/lib/jboss-messaging-int.jar" {
> permission java.security.AllPermission;
> };
> Unfortunately, it does not resolve the issue.
> I am also able to recreate the issue on EAP 5.1.0.
> [1] https://issues.jboss.org/browse/JBMESSAGING-1448
--
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
13 years, 9 months
[JBoss JIRA] (JBMESSAGING-1930) org.jboss.jms.server.container.SecurityAspect.check is missing privileged blocks
by Yong Hao Gao (JIRA)
[ https://issues.jboss.org/browse/JBMESSAGING-1930?page=com.atlassian.jira.... ]
Yong Hao Gao commented on JBMESSAGING-1930:
-------------------------------------------
OK I'll do it.
Thanks
Howard
> org.jboss.jms.server.container.SecurityAspect.check is missing privileged blocks
> --------------------------------------------------------------------------------
>
> Key: JBMESSAGING-1930
> URL: https://issues.jboss.org/browse/JBMESSAGING-1930
> Project: JBoss Messaging
> Issue Type: Bug
> Components: JMS Security
> Affects Versions: 1.4.8.SP5
> Reporter: Derek Horton
> Assignee: Yong Hao Gao
> Fix For: 1.4.8.SP8
>
> Attachments: JBPAPP-7335.patch
>
>
> A customer is trying to use the Java security manager on EAP 5.0.1. When the security manager is enabled, JBoss is throwing the following exception when they deploy their application that uses JMS:
> Caused by: java.security.AccessControlException: access denied (javax.management.MBeanPermission org.jboss.jms.server.jbosssx.JBossASSecurityMetadataStore#getSecurityMetadata[jboss.messaging:service=SecurityStore] invoke)
> at java.security.AccessControlContext.checkPermission(AccessControlContext.java:323)
> at java.security.AccessController.checkPermission(AccessController.java:546)
> at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
> at org.jboss.system.security.DebuggingJavaSecurityManager.checkPermission(DebuggingJavaSecurityManager.java:95)
> at org.jboss.mx.server.MBeanServerImpl.checkMBeanPermission(MBeanServerImpl.java:1735)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:663)
> at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> at $Proxy85.getSecurityMetadata(Unknown Source)
> at org.jboss.jms.server.container.SecurityAspect.check(SecurityAspect.java:285)
> at org.jboss.jms.server.container.SecurityAspect.handleCreateConsumerDelegate(SecurityAspect.java:113)
> 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.jboss.aop.advice.PerInstanceAdvice.invoke(PerInstanceAdvice.java:122)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> at org.jboss.jms.server.container.ServerLogInterceptor.invoke(ServerLogInterceptor.java:105)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> at org.jboss.jms.server.endpoint.advised.SessionAdvised.createConsumerDelegate(SessionAdvised.java)
> at org.jboss.jms.wireformat.SessionCreateConsumerDelegateRequest.serverInvoke(SessionCreateConsumerDelegateRequest.java:100)
> at org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSServerInvocationHandler.java:157)
> at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:930)
> at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
> at org.jboss.remoting.Client.invoke(Client.java:2034)
> at org.jboss.remoting.Client.invoke(Client.java:877)
> at org.jboss.remoting.Client.invoke(Client.java:865)
> at org.jboss.jms.client.delegate.DelegateSupport.doInvoke(DelegateSupport.java:189)
> I found a JIRA [1] that appears to resolve the issue in messaging versions 1.4.0.SP3.CP05, 1.4.1.GA, 1.4.2.GA. I tried adding the following grant statement to the java security policy file, hoping that would resolve the issue.
>
> grant codeBase "file:${jboss.home.dir}/common/lib/jboss-messaging-int.jar" {
> permission java.security.AllPermission;
> };
> Unfortunately, it does not resolve the issue.
> I am also able to recreate the issue on EAP 5.1.0.
> [1] https://issues.jboss.org/browse/JBMESSAGING-1448
--
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
13 years, 9 months
[JBoss JIRA] (AS7-2941) Problem deploying grails app
by Idar Borlaug (Created) (JIRA)
Problem deploying grails app
----------------------------
Key: AS7-2941
URL: https://issues.jboss.org/browse/AS7-2941
Project: Application Server 7
Issue Type: Bug
Affects Versions: 7.1.0.Beta1
Environment: Grails 1.3.4
Reporter: Idar Borlaug
Trying to deploy a grails 1.3.4 app on jboss 7.1.0.Beta1
The same app works fine on jboss 4.
12:26:44,722 ERROR [byfjell] (Thread-59) FrameworkEvent ERROR: org.apache.felix.log.LogException: org.osgi.framework.BundleException: Cannot resolve bundle resModule: [byfjell:0.1.0]
at org.jboss.osgi.framework.internal.ResolverPlugin.resolve(ResolverPlugin.java:157)
at org.jboss.osgi.framework.internal.AbstractBundleState.ensureResolved(AbstractBundleState.java:551)
at org.jboss.osgi.framework.internal.HostBundleState.startInternal(HostBundleState.java:211)
at org.jboss.osgi.framework.internal.AbstractBundleState.start(AbstractBundleState.java:494)
at org.jboss.as.osgi.deployment.BundleStartTracker$1.processService(BundleStartTracker.java:144)
at org.jboss.as.osgi.deployment.BundleStartTracker$1.transition(BundleStartTracker.java:119)
at org.jboss.msc.service.ServiceControllerImpl.invokeListener(ServiceControllerImpl.java:1429)
at org.jboss.msc.service.ServiceControllerImpl.access$2600(ServiceControllerImpl.java:49)
at org.jboss.msc.service.ServiceControllerImpl$ListenerTask.run(ServiceControllerImpl.java:1952)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [:1.6.0_22]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [:1.6.0_22]
at java.lang.Thread.run(Thread.java:679) [:1.6.0_22]
Caused by: org.apache.felix.log.LogException: org.jboss.osgi.resolver.XResolverException: Unable to resolve Module[byfjell:0.1.0]: missing requirement [Module[byfjell:0.1.0]] package; (&(package=javax.servlet)(version>=2.4.0)(!(version>=3.0.0)))
at org.jboss.osgi.resolver.felix.FelixResolver.resolveInternal(FelixResolver.java:117)
at org.jboss.osgi.resolver.spi.AbstractResolver.resolve(AbstractResolver.java:148)
at org.jboss.osgi.framework.internal.ResolverPlugin.resolve(ResolverPlugin.java:155)
--
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
13 years, 9 months
[JBoss JIRA] (HIBERNATE-133) Function to detach Hibernate managed object.
by jack luo (JIRA)
jack luo created HIBERNATE-133:
----------------------------------
Summary: Function to detach Hibernate managed object.
Key: HIBERNATE-133
URL: https://issues.jboss.org/browse/HIBERNATE-133
Project: Hibernate Integration
Issue Type: Feature Request
Environment: Hibernate core.
Reporter: jack luo
Assignee: Steve Ebersole
Currently, after retrieving data from database by hibernate like:
User user = session.get(User.class, id);
Then user object will become a hibernated managed object (po), if try to invoke any "lazy" property which haven't been initialized then it will throw an famous "LazyInitializationException". But so often, in web service or other scenarios, we need to serialize the object returned by Hibernate query, serializer doesn't know which properties are "lazy" field and haven't been initialized, then in serializing, it will throw an ""LazyInitializationException" exception which will stop the whole thing working. I found Session.evict(Object proxy) and Session.clear() seems might do the work that detaching PO from Hibernate, but it doesn't. I still got the error. After spent days searching in the internet, I found out there isn't any easy way to convert an PO to a POJO (detaching PO from Hibernate thoroughly), actually many people have implemented so many solutions like removing all the proxies from PO or copy PO to an POJO (DTO some people call it), any solution comes with cost of the system apparently. Well, if Hibernate can provide a simple function Hibernate.detach(Object obj) which will return an pure POJO then it will make our life so much easier. Check this link out, you see how many people have been struggling with this issue since 2008?
http://www.mojavelinux.com/blog/archives/2006/06/hibernate_get_out_of_my_...
My first try on Hibernate was back to 2007 and I found this issue, ending up copying properties of PO to a POJO to avoid "LazyInitializationException" exception. I absolute got the idea of lazy loading but DAO layer will pass the object to Business/View layer, I don't think they're responsible to check if every property's initialized by Hibernate before using it. It ok that un-initialized properties are null but throwing an exception is unacceptable. Requirement is quite straight forward, just want a pure POJO.
--
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
13 years, 9 months
[JBoss JIRA] (JBMESSAGING-1930) org.jboss.jms.server.container.SecurityAspect.check is missing privileged blocks
by Derek Horton (JIRA)
[ https://issues.jboss.org/browse/JBMESSAGING-1930?page=com.atlassian.jira.... ]
Derek Horton commented on JBMESSAGING-1930:
-------------------------------------------
Howard,
I have attached a patch that appears to resolve this issue. The patch was built against https://svn.jboss.org/repos/messaging/branches/Branch_1_4 and tested on EAP 5.1.2.
Can you review this and apply it upstream so that it is included in EAP 5.1.3.
Thanks,
Derek
> org.jboss.jms.server.container.SecurityAspect.check is missing privileged blocks
> --------------------------------------------------------------------------------
>
> Key: JBMESSAGING-1930
> URL: https://issues.jboss.org/browse/JBMESSAGING-1930
> Project: JBoss Messaging
> Issue Type: Bug
> Components: JMS Security
> Affects Versions: 1.4.8.SP5
> Reporter: Derek Horton
> Assignee: Yong Hao Gao
> Fix For: 1.4.8.SP8
>
> Attachments: JBPAPP-7335.patch
>
>
> A customer is trying to use the Java security manager on EAP 5.0.1. When the security manager is enabled, JBoss is throwing the following exception when they deploy their application that uses JMS:
> Caused by: java.security.AccessControlException: access denied (javax.management.MBeanPermission org.jboss.jms.server.jbosssx.JBossASSecurityMetadataStore#getSecurityMetadata[jboss.messaging:service=SecurityStore] invoke)
> at java.security.AccessControlContext.checkPermission(AccessControlContext.java:323)
> at java.security.AccessController.checkPermission(AccessController.java:546)
> at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
> at org.jboss.system.security.DebuggingJavaSecurityManager.checkPermission(DebuggingJavaSecurityManager.java:95)
> at org.jboss.mx.server.MBeanServerImpl.checkMBeanPermission(MBeanServerImpl.java:1735)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:663)
> at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> at $Proxy85.getSecurityMetadata(Unknown Source)
> at org.jboss.jms.server.container.SecurityAspect.check(SecurityAspect.java:285)
> at org.jboss.jms.server.container.SecurityAspect.handleCreateConsumerDelegate(SecurityAspect.java:113)
> 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.jboss.aop.advice.PerInstanceAdvice.invoke(PerInstanceAdvice.java:122)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> at org.jboss.jms.server.container.ServerLogInterceptor.invoke(ServerLogInterceptor.java:105)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> at org.jboss.jms.server.endpoint.advised.SessionAdvised.createConsumerDelegate(SessionAdvised.java)
> at org.jboss.jms.wireformat.SessionCreateConsumerDelegateRequest.serverInvoke(SessionCreateConsumerDelegateRequest.java:100)
> at org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSServerInvocationHandler.java:157)
> at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:930)
> at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
> at org.jboss.remoting.Client.invoke(Client.java:2034)
> at org.jboss.remoting.Client.invoke(Client.java:877)
> at org.jboss.remoting.Client.invoke(Client.java:865)
> at org.jboss.jms.client.delegate.DelegateSupport.doInvoke(DelegateSupport.java:189)
> I found a JIRA [1] that appears to resolve the issue in messaging versions 1.4.0.SP3.CP05, 1.4.1.GA, 1.4.2.GA. I tried adding the following grant statement to the java security policy file, hoping that would resolve the issue.
>
> grant codeBase "file:${jboss.home.dir}/common/lib/jboss-messaging-int.jar" {
> permission java.security.AllPermission;
> };
> Unfortunately, it does not resolve the issue.
> I am also able to recreate the issue on EAP 5.1.0.
> [1] https://issues.jboss.org/browse/JBMESSAGING-1448
--
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
13 years, 9 months