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

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

by adrian＠jboss.org

"david.lloyd(a)jboss.com" wrote : Just a note that vfs* handlers in the bootstrap lib don't have to be the real handlers, they can just be do-nothing stubs, since there is the opportunity to plug in a real URLStreamHandlerFactory at a later time. I'm not sure that would work. From my experience the URL stuff does some funny caching? An alternative solution is to change the way the VFSClassLoaderPolicy determines the code source. i.e. instead of returning the vfs url we could hack it to return a normal url. But this would restrict codesources to be the top level url, you couldn't for example have different permissions for subdeployments in the same deployment. The relevant code is in VFSClassLoaderPolicy | @Override | protected ProtectionDomain getProtectionDomain(String className, String path) | { | VirtualFile clazz = findChild(path); | if (clazz == null) | { | log.trace("Unable to determine class file for " + className); | return null; | } | try | { | VirtualFile root = findRoot(path); | | // HERE!!!!!!!! | | URL codeSourceURL = root.toURL(); | This could for example be replaced with something like: | URL codeSourceURL = VFSUtils.getRealURLHack(root); | An alternative solution would be to allow you to specify the codeSourceURL to use for the classloader as a parameter when you create it. The hack could then be in the jboss deployer that creates the classloader policy rather than forcing it on every user of VFSClassLoaderPolicy. i.e. people that use it standalone would probably include jboss-vfs.jar in the classpath so the urls would be parsable? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4187460#4187460 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4187460

17 years, 5 months

1
0
0 / 0

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

by adrian＠jboss.org

"anil.saldhana(a)jboss.com" wrote : | | 11:19:11,025 ERROR [AbstractKernelController] Error installing to Create: name=AspectManager state=Configured | | java.security.AccessControlException: access denied (java.io.FilePermission /home/anil/jboss-5.0/jboss-head/build/output/jboss-5.0.0.GA/server/default/tmp/aopdynclasses read) | | at java.security.AccessControlContext.checkPermission(AccessControlContext.java:264) | | | | That is the error I am trying to get rid of that is not allowing a boot. You don't show the full stacktrace, but this is on the bootstrap thread isn't it? If you've correctly given all the jboss jars the AllPermission then there shouldn't be any problem here with accessing the file system. My guess is that you haven't given them the AllPermission because of the code source being a vfs url. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4187455#4187455 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4187455

17 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: creating integration layer

by timfox

I don't think util needs to be in its own jar. I'd go for: jbm-core.jar (pure core stuff) jbm-jms.jar (jms stuff) jbm-core-client.jar (pure core client stuff only) jbm-transports.jar jbm-jbossas-security.jar jbm-logging.jar jbm-bootstrap.jar View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4187453#4187453 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4187453

17 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Any reason why producer auto group id is generated on the se

by timfox

The current code generates this on the server then sends it back to the client in the response packet. Any reason why this is necessary? Can't it just be generated on the client, then there's no need to send it over the network..? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4187449#4187449 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4187449

17 years, 5 months

1
0
0 / 0

[Design of EJB 3.0] - Re: jboss.entity.manager.factory.jndi.name

by wolfc

It's in jboss-jpa-deployers 1.0.0-Beta2, but that one is also causing regression https://jira.jboss.org/jira/browse/JBAS-6165. I'm in the process of cutting jboss-jpa-deployers 1.0.0-Beta3. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4187448#4187448 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4187448

17 years, 5 months

1
0
0 / 0

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

by david.lloyd＠jboss.com

Just a note that vfs* handlers in the bootstrap lib don't have to be the real handlers, they can just be do-nothing stubs, since there is the opportunity to plug in a real URLStreamHandlerFactory at a later time. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4187446#4187446 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4187446

17 years, 5 months

1
0
0 / 0

[Design of POJO Server] - JBVFS-67, VFSCacheFactory.getInstance(String defaultCacheImp

by scott.stark＠jboss.org

I want to add a VFSCacheFactory.getInstance(String defaultCacheImpl) factory method so we can set the cache to use in the beans descriptor rather than having to set a system property. I would say this value takes precedence over the system property: | public static VFSCache getInstance() | { | return getInstance(null); | } | public static VFSCache getInstance(String defaultCacheImpl) | { | if (instance == null) | { | synchronized (lock) | { | if (instance == null) | instance = AccessController.doPrivileged(new VFSCacheCreatorAction(defaultCacheImpl)); | } | } | return instance; | } | | private static class VFSCacheCreatorAction implements PrivilegedAction<VFSCache> | { | private String defaultCacheImpl; | VFSCacheCreatorAction(String defaultCacheImpl) | { | this.defaultCacheImpl = defaultCacheImpl; | } | | public VFSCache run() | { | try | { | String className = defaultCacheImpl; | if(className == null) | className = System.getProperty(VFSUtils.VFS_CACHE_KEY); | if (className != null) | { | log.info("Initializing VFSCache [" + className + "] ..."); | ClassLoader cl = VFSCacheFactory.class.getClassLoader(); | Class<?> clazz = cl.loadClass(className); | VFSCache cache = VFSCache.class.cast(clazz.newInstance()); | cache.start(); // start here, so we fall back to default no-op in case start fails | log.info("Using VFSCache [" + cache + "] ..."); | return cache; | } | } | catch (Throwable t) | { | log.warn("Exception instantiating VFS cache: " + t); | } | log.info("Using VFSCache [NoopVFSCache] ..."); | return new NoopVFSCache(); | } | } | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4187445#4187445 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4187445

17 years, 5 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Possible problem with bean-deployer_2_0.xsd

by adrian＠jboss.org

"adrian(a)jboss.org" wrote : | But I'd guess from this link (see the table) that you are not allowed to | derive a choice from a choice except under very specific circumstances? | http://www.w3.org/TR/xmlschema-1/#cos-particle-restrict | >From that link: anonymous wrote : | One of the following must be true: | 2.2.1 {particles} is empty and the particle within which this appears has {min occurs} of 0. | 2.2.2 All of the following must be true: | 2.2.2.1 The particle within which this appears has {max occurs} and {min occurs} of 1. | ... | This isn't true for baseCollectionType which has an unbounded choice | <xsd:complexType name="baseCollectionType"> | | <xsd:choice minOccurs="0" maxOccurs="unbounded"> | | <xsd:group ref="valueGroup"/> | | </xsd:choice> | | ... | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4187442#4187442 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4187442

17 years, 5 months

1
0
0 / 0

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

by anil.saldhana＠jboss.com

| 11:19:11,025 ERROR [AbstractKernelController] Error installing to Create: name=AspectManager state=Configured | java.security.AccessControlException: access denied (java.io.FilePermission /home/anil/jboss-5.0/jboss-head/build/output/jboss-5.0.0.GA/server/default/tmp/aopdynclasses read) | at java.security.AccessControlContext.checkPermission(AccessControlContext.java:264) | anonymous wrote : | | | | That is the error I am trying to get rid of that is not allowing a boot. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4187441#4187441 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4187441

17 years, 5 months

1
0
0 / 0

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

by scott.stark＠jboss.org

Yes, its back to having either vfs* url handlers available to the bootstrap lib or a Policy that deals with them. Its silly that CodeSource still uses a URL rather than URI since the URL contents are never used. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4187440#4187440 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4187440

17 years, 5 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