December 2007 - jboss-dev-forums - Jboss List Archives

[Design the new POJO MicroContainer] - Re: Security access

by adrian＠jboss.org

I don't see these tests fail running under Maven or Eclipse. So this must be something specific to your environment, e.g. have you checked into a folder with the word "tests" in it? The security policy used is here: http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/projects/test/trunk/sr... | // Is this a test location? | File file = new File(url.toString()); | String name = file.getName(); | if (name.indexOf("tests") != -1 || name.indexOf("test-classes") != -1 || name.indexOf("-test.jar") != -1) | What you need to do, is to print out the code source and permissions for each of the class in the stacktrace until you reach one that has the permission. Adding a privileged block makes no difference if that class doesn't have the permission. In fact it makes it worse. ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4113056#4113056 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4113056

18 years, 3 months

1
0
0 / 0

[Design of POJO Server] - Re: BSH script from client

by alesj

"scott.stark(a)jboss.org" wrote : The .bsh suffix needs to be added to the FileStructure in order for these scripts to be recognized as deployable | This is added via FileMatcher. | public class LegacyBeanShellDeployer extends AbstractVFSParsingDeployer<BeanShellScript> implements FileMatcher | Where FileStructure has this: | @Install | public boolean addFileMatcher(FileMatcher fm) | { | return fileMatchers.add(fm); | } | | @Uninstall | public boolean removeFileMatcher(FileMatcher fm) | { | return fileMatchers.remove(fm); | } | and | protected boolean checkFileMatchers(VirtualFile file) | { | for(FileMatcher fm : fileMatchers) | { | if (fm.isDeployable(file)) | return true; | } | return false; | } | So, by what you're saying, this is should already work. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4113054#4113054 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4113054

18 years, 3 months

1
0
0 / 0

[Design of POJO Server] - Re: BSH script from client

by scott.stark＠jboss.org

The following jaas-service.xml is deployed fine: | [starksm@succubus lib]$ jar -tf client-login-tests.jar | META-INF/MANIFEST.MF | org/jboss/test/security/clientlogin/BeanA.class | org/jboss/test/security/clientlogin/BeanB.class | org/jboss/test/security/clientlogin/BeanC.class | org/jboss/test/security/clientlogin/IClientLogin.class | org/jboss/test/security/clientlogin/IClientLoginHome.class | jaas-service.xml | META-INF/ejb-jar.xml | META-INF/jboss.xml | because jaas-service.xml is a context with a null metadata location, hence itself matches the metadata file. Its the identification of the structure that determines which contexts are deployment candidates. The .bsh suffix needs to be added to the FileStructure in order for these scripts to be recognized as deployable: |  | <bean name="FileStructure" class="org.jboss.deployers.vfs.plugins.structure.file.FileStructure"> |  | <constructor> | <parameter> | <set elementClass="java.lang.String"> | <value>-service.xml</value> | <value>-beans.xml</value> | <value>-ds.xml</value> | <value>-aop.xml</value> | </set> | </parameter> | </constructor> | </bean> | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4113049#4113049 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4113049

18 years, 3 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Security access

by scott.stark＠jboss.org

Send it to me and I should be able to see the relevant failure msg. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4113039#4113039 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4113039

18 years, 3 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Security access

by alesj

"scott.stark(a)jboss.org" wrote : To get debugging from the SecurityManager layer, add a -Djava.security.debug=all to the run. It will print out a lot of info about the policy, access, and failures. | I already did that. And it was really really a lot, so I gave up. :-( But will re-try to find something useful. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4113038#4113038 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4113038

18 years, 3 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Security access

by scott.stark＠jboss.org

To get debugging from the SecurityManager layer, add a -Djava.security.debug=all to the run. It will print out a lot of info about the policy, access, and failures. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4113036#4113036 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4113036

18 years, 3 months

1
0
0 / 0

[Design of POJO Server] - Re: BSH script from client

by alesj

Scott, you said -service.xml can be where ever? Or which file? Since SARDeployer extends JAXPDeployer JAXPDeployer extends AbstractVFSParsingDeployer. Where AbstractVFSParsingDeployer uses this to find files with suffix: | protected T parse(DeploymentUnit unit, String name, String suffix, T root) throws Exception | { | // Should we include the deployment | // The infrastructure will only check leafs anyway so no need to check here | if (name == null && isIncludeDeploymentFile()) | name = unit.getName(); | | // Try to find the metadata | VFSDeploymentUnit vfsDeploymentUnit = (VFSDeploymentUnit) unit; | List<VirtualFile> files = vfsDeploymentUnit.getMetaDataFiles(name, suffix); | if (files.size() == 0) | return null; | | // TODO JBMICROCONT-184 remove this limitation | if (files.size() > 1) | throw new DeploymentException("Only one file is allowed, found=" + files); | | VirtualFile file = files.get(0); | | T result = parse(vfsDeploymentUnit, file, root); | if (result != null) | init(vfsDeploymentUnit, result, file); | return result; | } | 'vfsDeploymentUnit.getMetaDataFiles(name, suffix)' Meaning only metadata files are checked. What would be needed to handle .bsh file anywhere? A new BshStructure? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4113035#4113035 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4113035

18 years, 3 months

1
0
0 / 0

[Design of JBossCache] - Re: New state transfer in JBoss Cache

by bela＠jboss.com

I thought about state transfer today, and it is significantly more complex than I had previously thought. I'm not referring to correct state with respect to other messages, we can use digests for that. The complexity lies in getting the state at the state provider *while* it is being updated, e.g. by transactions from other nodes. More thought needed next week... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4113034#4113034 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4113034

18 years, 3 months

1
0
0 / 0

[Design of JBossCache] - Re: New state transfer in JBoss Cache

by manik.surtani＠jboss.com

Yes, active-passive could also work with these low-prio threads working off different disjoint data sets on different "providers" simultaneously. The only problem here is maintaining integrity of the state when there are other threads updating the state at the same time - the state may be outdated. But then again, assuming updates are idempotent and that the joiner is queueing up updates while waiting for state, this shouldn't be a problem. The only drawback is that it may take a lot longer (significantly longer if the state provider thread is low-prio) for the joiner to get state, but that shouldn't be a problem in an active-passive scenario. I think providing pluggable policies/mechanisms for state transfer may be a good thing as well, since a "one size fits all" solution for ST almost certainly won't work. Just means cleaner abstraction between state transfer and normal cache operations, but a lot of forethought into what ST may involve when designing an SPI for this. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4113026#4113026 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4113026

18 years, 3 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Multiple metadata locations

by alesj

18 years, 3 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 December 2007