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

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

by adrian＠jboss.org

"adrian(a)jboss.org" wrote : | I don't like it refactored or otherwise because it is wrong. | | There are two different issues: | | 1) Which codesource should it use? | | i.e. should it use the top level file: url like JBoss4 or a vfs url as the codesource | This is what you CodeSourceGenerator abstraction is trying to do, but it is a hack | and it also only applied to the vfs classloading spi? | I say it is a hack because it is not the job of the classloader to map vfs urls to other urls. We should be asking to the VFS subsystem to do this. This kind of negates the need for the CodeSourceGenerator abstraction altogether with the only question being a policy of which url you use as the code source. (The permissions should be the same regardless of how you identify the code). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4188112#4188112 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4188112

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 : "alesj" wrote : "anil.saldhana(a)jboss.com" wrote : | | | At this time, I just change the protocol to be "file" instead of the vfs protocol. | | Anil, I've refactored your code a bit. | | | | Leaving the old behavior as default - via your CodeSourceGenerator, | | but I'll provide proper hooks so that this can be overridden in the CL deployers that use VFSCLPolicy. | | | | If Adrian agrees this is a proper fix. ;-) | | I like your refactor. Are you going to provide the hooks by Monday? I want to enable the security manager tests in AS5 asap. I also have changes that I need to check in changes in AS5 code (privileged blocks) as part of that. I don't like it refactored or otherwise because it is wrong. There are two different issues: 1) Which codesource should it use? i.e. should it use the top level file: url like JBoss4 or a vfs url as the codesource This is what you CodeSourceGenerator abstraction is trying to do, but it is a hack and it also only applied to the vfs classloading spi? If we are going to go to the effort of introducing a proper spi for this, then we should look at how you override the real purpose of this policy, i.e. determing the whole ProtectionDomain. There should also be easier ways to set this policy, i.e. on the ClassLoaderDomain or the ClassLoaderSystem itself. The FileProtocolCodeSourceGenerator is wrongly implemented anyway. e.g. vfsfile:/some/directory/my.jar/sub.jar would result it a file url that is invalid file:/some/directory/my.jar/sub.jar I also don't see the need for the permission to set the codesource generator. If somebody can get access to the policy then can make all sorts of other changes anyway. Getting access to the classloader implementation objects is already controlled by | sm.checkCreateClassLoader(); | checks. 2) What permissions should it have? i.e. do you get the necessary FilePermission, checkConnection and NetPermissions? If you change the code source to be a file: url for the parsing of java.policy then you are going to loose the rights to use vfsxxx url (and vice versa). That's besides the problem mentioned above with the wrong file url getting used. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4188107#4188107 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4188107

17 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Netty exception in Hudson run

by timfox

Unfortunately 3.0.1.snapshot 5 seems to have been removed from the repository. Trustin - where can I find this? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4188106#4188106 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4188106

17 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Why does DeleteEncoding need a queue id?

by timfox

JournalStorageManager. | void storeDelete(long messageID) throws Exception; | | void storeDeleteMessageTransactional(long txID, long queueID, long messageID) throws Exception; | Why do we need the queue id when storing a delete transactionally? We don't need it when deleting non transactioally. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4188086#4188086 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4188086

17 years, 5 months

1
0
0 / 0

[Design of JBossCache] - Re: SELECT FOR UPDATE semantics

by manik.surtani＠jboss.com

In fact, I am going to add this to the 3.x FAQs View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4188078#4188078 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4188078

17 years, 5 months

1
0
0 / 0

[Design of JBossCache] - Re: SELECT FOR UPDATE semantics

by manik.surtani＠jboss.com

Actually, it is supported. :-) Just do this: | // start transaction ... | cache.getInvocationContext().getOptionOverrides().setForceWriteLock(true); | Node n = cache.get("/a/b/c"); // this acquires a WRITE LOCK on this node | ... | ... | // end transaction | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4188077#4188077 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4188077

17 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Netty exception in Hudson run

by timfox

I've reverted from 3.0.1.GA back to 3.0.1.snapshot5, to see if it solves the failures. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4188076#4188076 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4188076

17 years, 5 months

1
0
0 / 0

[Design of JBoss ESB] - Re: ESB Action transactions and synhronization questions

by Kevin.Conner＠jboss.com

It is not used in the scheduled listener case, but for all other listeners it will be. If you use a POJO as an action then a new instance will be created for every message passing through the pipeline. This is for historical reasons. If your action implements the ActionPipelineProcessor or ActionLifecycle interfaces then there will be a single instance created for each pipeline (incoming transport). The action must be thread safe as it is possible for multiple threads to access it concurrently. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4188069#4188069 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4188069

17 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: JBAS-5953; jar override issue

by alesj

"adrian(a)jboss.org" wrote : | If Ales can't find a problem in the VFS | I've added assertTrue(thejar.delete()) before every Files::copy. If I run AS with -Djboss.vfs.noReaper=true test passes every time, w/o that flag it fails on newly added assert before 2nd Files::copy. I already have VFSUtils::enableNoReaper(VirtualFile), but looks like it's kicking in too late. I'm checking if VFSUtils::enableNoReaper(VFS) can do the trick. (need to add that method first :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4188067#4188067 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4188067

17 years, 5 months

1
0
0 / 0

[Design of JBoss Identity] - Re: SAML Assertions

by jeff.yuchang

"jkurtz.wa(a)gmail.com" wrote : "mark.little(a)jboss.com" wrote : "anil.saldhana(a)jboss.com" wrote : John, what would be the various integration points in ESB? From my recollection, the ESB message can contain security context. So an action can be an integration point. | | | | | | | It could be enforced within an action, or within filters. Since filters are imposed by the infrastructure and do not rely on the application or service configuration being right (or deliberately spoofed) they would seem to be more appropriate. | | Mark, could you elaborate on this? This is really an important point. I am going to look for some examples of filters and will work through the examples to understand further. Hi John, As Mark mentioned the filter, it reminds me of this great feature. So today, I've looked into the filter feature again. Have some thoughts on adding security feature by using filter. Right now, we extract the security information in the Gateway, and then do the authentication in the service actionProcessingPipeline. With introducing a securityFilter, we will do the extraction work on the onOutput(...), which before leaving Gateway. onInput(...) will do the seucirty enforcement. And then we just need to configure the $jbossesb/server/default/jbossesb.sar/jbossesb-properties.xml by adding the securityFilter. In this way, the security feature becomes very pluggable. If I understands codes correctly. The process will be like: | Message -> Gateway -> Filter.doOuput -> Transport -> Filter.onInput -> Service1 -> Filter.onOutput -> Transport ->.... | So the Gateway will only has the Filter.onOutput, no onInput though. But for service level, it has both onInput and onOutput. Hope this Helps. Jeff View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4188061#4188061 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4188061

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