November 2008 - jboss-dev-forums - Jboss List Archives

[Design of POJO Server] - Re: VFS Permissions - JBMICROCONT-149

by anil.saldhana＠jboss.com

"scott.stark(a)jboss.org" wrote : If we need to be able to assign permissions to vfsmemory urls, then it should map to the codebase from which the aspect was loaded in terms of having consistent permission assignments. It should just be inheriting the permissions of the aspect codebase. I don't see a usecase for assigning a separate permission to the generated code from the aspect. For AS5GA, we are taking that approach by at least adding privileged blocks to users of aspects (such as ejb3, mc etc). Examples: https://jira.jboss.org/jira/browse/JBMICROCONT-385 Disclaimer: I am neither AOP nor VFS expert. I am also not Adrian Brock. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4189481#4189481 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4189481

17 years, 4 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Broken build

by timfox

I've had a deeper look into way the build started failing recently/ Whilst it is true it was actually the randomfailovertest failing (Jeff was right), the reason for this seems to be the following in the logs: | (group:JBM-InVM-Transport-Threads-31601333):) Failed to delete consumer | javax.management.InstanceNotFoundException: org.jboss.messaging:module=Core,type=Queue,address="FailoverTestAddress",name="FailoverTestAddress" | at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.unregisterMBean(DefaultMBeanServerInterceptor.java:374) | at com.sun.jmx.mbeanserver.JmxMBeanServer.unregisterMBean(JmxMBeanServer.java:527) | at org.jboss.messaging.core.management.impl.ManagementServiceImpl.unregisterFromJMX(ManagementServiceImpl.java:360) | at org.jboss.messaging.core.management.impl.ManagementServiceImpl.unregisterResource(ManagementServiceImpl.java:298) | at org.jboss.messaging.core.management.impl.ManagementServiceImpl.unregisterQueue(ManagementServiceImpl.java:228) | at org.jboss.messaging.core.postoffice.impl.PostOfficeImpl.removeBinding(PostOfficeImpl.java:239) | at org.jboss.messaging.core.server.impl.ServerSessionImpl.doHandleDeleteQueue(ServerSessionImpl.java:580) | at org.jboss.messaging.core.server.impl.ServerSessionImpl.handleDeleteQueue(ServerSessionImpl.java:555) | at org.jboss.messaging.core.server.impl.ServerSessionPacketHandler.handlePacket(ServerSessionPacketHandler.java:127) | at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl$ChannelImpl.handlePacket(RemotingConnectionImpl.java:1306) | at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl$ChannelImpl.access$1(RemotingConnectionImpl.java:1242) | at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:438) | at org.jboss.messaging.core.remoting.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:322) | at org.jboss.messaging.core.remoting.impl.invm.InVMConnection$1.run(InVMConnection.java:118) | at org.jboss.messaging.util.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:105) | at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650) | at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675) | at java.lang.Thread.run(Thread.java:595) | This only started to occur (failing most test runs) after svn revision 5361, which contains the following change: | - ManagementService managementService = new ManagementServiceImpl(ManagementFactory.getPlatformMBeanServer(), false); | + ManagementService managementService = new ManagementServiceImpl(ManagementFactory.getPlatformMBeanServer(), config.isJMXManagementEnabled()); | So basically now jmx server is enabled by default, previously it wasn't. This would explain why we only see the error after the commit. I have put a temporary hack in postoffficeImpl:removeBinding to get the suite to run ok, but this needs to be solved properly. I suspect it's being called after the managementservice has shutdown. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4189480#4189480 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4189480

17 years, 4 months

1
0
0 / 0

[Design of POJO Server] - Re: VFS Permissions - JBMICROCONT-149

by david.lloyd＠jboss.com

Correct me if I'm wrong though, but isn't that one of the usecases of aspects themselves? You can limit the permissions of codebase X and use aspects to wrap unprivileged code with a privileged operation like set up TCCL/transaction context/security context/etc.? In this case, the permissions of the aspect would be the aspect codebase plus some small fixed set of permissions. Though perhaps in this case it would be up to the aspect deployment to specify this? Disclaimer: I'm no AOP expert :) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4189478#4189478 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4189478

17 years, 4 months

1
0
0 / 0

[Design of POJO Server] - Re: xml persistent format for attachments

by scott.stark＠jboss.org

Good point, the main drawback that has been raised is a completely different format from the original deployment descriptor. Reliability of the attachment serialization/deserialization would definitely be a priority though. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4189476#4189476 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4189476

17 years, 4 months

1
0
0 / 0

[Design of POJO Server] - Re: VFS Permissions - JBMICROCONT-149

by scott.stark＠jboss.org

If we need to be able to assign permissions to vfsmemory urls, then it should map to the codebase from which the aspect was loaded in terms of having consistent permission assignments. It should just be inheriting the permissions of the aspect codebase. I don't see a usecase for assigning a separate permission to the generated code from the aspect. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4189475#4189475 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4189475

17 years, 4 months

1
0
0 / 0

[Design of POJO Server] - Re: VFS Permissions - JBMICROCONT-149

by anil.saldhana＠jboss.com

"alesj" wrote : "anil.saldhana(a)jboss.com" wrote : Issues: | | a) AOP uses vfsmemory:// pattern. Not sure about assigning perms to a codesource URL in memory. Maybe vfs real url may help. | And there are others - assembled stuff --> vfs://. | Plus users can add their own protocols. ;-) | | Dunno what to do about those, | as they don't have logical 'real' representation. We can deal with custom protocols. But we would need some static content in the URL that goes into the codesource url. Something like: <protocol>://<static>/<dynamic> | | vfsmemory://jboss/microcontainer/uuid-string | Then the onus is on the system administrator to adequately assign permissions. I still see issues with rogue applications trying to mess in memory. Maybe Scott/Adrian can think of something.... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4189474#4189474 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4189474

17 years, 4 months

1
0
0 / 0

[Design of POJO Server] - Re: VFS Permissions - JBMICROCONT-149

by david.lloyd＠jboss.com

(100th reply!!!!) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4189468#4189468 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4189468

17 years, 4 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Why ServerSessionImpl::doHandleCreateQueue is not callin

by timfox

The post office maintains a set of queues bound to an address, the post office also maintains a set of "allowable destinations" (see the code). If postoffice.checkallowable = true then the post office will only allow messsages to be routed to allowable destinations. In other words it's a way of restricting the set of addresses to which you are allowed to route. This is useful for JMS, since JMS prohibits routing to addresses (JMS queues or topics) which "do not exist". Without such an address we wouldn't have any way of determining if such an address exists. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4189463#4189463 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4189463

17 years, 4 months

1
0
0 / 0

[Design of POJO Server] - Re: VFS Permissions - JBMICROCONT-149

by david.lloyd＠jboss.com

There ought to be a way for AOP (and anyone else using vfsmemory) to assign a symbolic (repeatable) name to the codesource. Obviously this would have to be established in a secure manner though (so that you couldn't just take someone else's name to get their permissions). This way, users could reasonably assign permissions to their code, but also the code that their code generates. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4189462#4189462 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4189462

17 years, 4 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Why ServerSessionImpl::doHandleCreateQueue is not callin

by clebert.suconic＠jboss.com

I still don't understand why the JMS Queue needs a Destination, while the Core Queue doesn't. I understand about the Topics requiring the Destination. But what about the core Queues? Shouldn't both queues work the same way, i.e. or Having a Destination or not having it? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4189451#4189451 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4189451

17 years, 4 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-dev-forums November 2008