January 2009 - jboss-dev-forums - Jboss List Archives

[Design the new POJO MicroContainer] - Re: Security services deployer for the MC

by scott.stark＠jboss.org

The usecase for having something like this in an mc subproject would be adding support for hashed and encrypted property values in the xml descriptors. Right now the jca mbeans have support for this, but it should be a generic facility. The jca mbeans rely on communicating with a JaasSecurityDomain. This should be generalized into a security aspect. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204028#4204028 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204028

17 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Security services deployer for the MC

by david.lloyd＠jboss.com

This module in no way has any overlap with any authentication or authorization system. It is merely a way to declare objects defined in java.security and javax.crypto as POJOs which can be injected, to allow configuration and data to be separated from logic; a class IoC use case in my opinion. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204024#4204024 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204024

17 years, 2 months

1
0
0 / 0

[Design of JBoss Transaction Services] - Re: JTA/JTS thread disassociation semantics

by mark.little＠jboss.com

No, if a compliant ORB is supposed to throw OBJECT_NOT_EXIST if there's a call on a reference/IOR to a non-persistent instance that it can no longer find. This is different to, say, COMM_FAILURE or one of the other low-level SystemExceptions. In the case of a timeout the transaction will be garbage collected and remove itself from the POA, which will mean any outstanding requests from remote clients should (assuming the ORB works) get back OBJECT_NOT_EXIST. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204021#4204021 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204021

17 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Generated Classes not found if they do not match any of

by kabir.khan＠jboss.com

Actually, this is a problem for the AOP proxies, which may be in the default package when creating a proxy for something in packages starting with java. or sun. Digging into this I found the following: | ClassLoader loaderA = //ClassLoader belonging to DefaultDomain with package a | ClassLoader loaderB = //ClassLoader belonging to DefaultDomain with package b | | //These all work | Class<?> aA = loaderA.loadClass("a.A"); | Class<?> bB = loaderB.loadClass("b.B"); | Class<?> bA = loaderB.loadClass("a.A"); | Class<?> aB = loaderA.loadClass("b.B"); | | //Define a new class x.X in loaderA | CtClass clazz = poolA.makeClass("x.X"); //poolA uses loaderA | Class<?> x = clazz.toClass(); //defined using loaderA | Class<?> a.X = clazz.loadClass("x.X"); //works | Class<?> bX = clazz.loadClass("x.X"); throws ClassNotFoundException | The call to toClass() ends up here in JBossClDelegatingClassPool | public Class<?> toClass(ToClassInvokerPoolReference pool, CtClass cc, String classFileName, ClassLoader loader, ProtectionDomain domain) throws CannotCompileException | { | ... | try | { | URL outputURL = new URL(tempURL.toString() + "/" + classFileName); | //Write the classfile to the temporary url | synchronized (tmplock) | { | if (trace) logger.trace(this + " " + pool + ".toClass() myloader:" + myloader + " writing bytes to " + tempURL); | ByteArrayOutputStream byteout = new ByteArrayOutputStream(); | BufferedOutputStream out = new BufferedOutputStream(byteout); | out.write(cc.toBytecode()); | out.flush(); | out.close(); | | byte[] classBytes = byteout.toByteArray(); | MemoryContextFactory factory = MemoryContextFactory.getInstance(); | factory.putFile(outputURL, classBytes); | | if (myloader instanceof RealClassLoader) | { | ((RealClassLoader)myloader).clearBlackList(classFileName); | } | | Class<?> clazz = myloader.loadClass(cc.getName()); | if (trace) logger.trace(this + " " + pool + " myloader:" + myloader + " created class:" + clazz); | return clazz; | } | } | catch(Exception e) | { | ClassFormatError cfe = new ClassFormatError("Failed to load dyn class: " + cc.getName() + " on " + this + " loader:" + myloader); | cfe.initCause(e); | throw cfe; | } | } | It adds the class bytes to the vfs memory context associated with loaderA. Next it loads the class. Internally this hits the domain first, and x.X gets added to the domain's globalClassBlackList. When the class is not found in the domain, it tries the initiating loader (loaderA), which can load the class. When we try to load the class using loaderB, it cannot find the class using loaderB since loaderB will hit the domain, and the class is in the globalClassBlackList. This should be fixable by making BaseClassLoader.clearBlackList also remove the entry from its domain's globalClassBlackList? However, the next problem then becomes updating the domain's classLoadersByPackageName since it knows nothing about package "x". I will see if I can recreate this somehow with a test in jboss-cl, and propose a fix. What I have mentioned so far is for the mode where everything is visble in the whole domain. There will probably be further problems with OSGi style loading since we then need to update the modules? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204018#4204018 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204018

17 years, 2 months

1
0
0 / 0

[Design of JBoss Transaction Services] - Re: JTA/JTS thread disassociation semantics

by jhalliday

So in the case of a commit from another thread the object hangs around rather than getting thrown away? Otherwise the translation is suspect... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204015#4204015 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204015

17 years, 2 months

1
0
0 / 0

[Design of JBoss Transaction Services] - Re: JTA/JTS thread disassociation semantics

by mark.little＠jboss.com

"jhalliday" wrote : | But that won't work in distributed cases, since the tx is remote which means we either need it to hang around as long as a client has a handle on it (i.e. it's a distributed gc problem) or we need to notify all the clients of the outcome when it terminates (i.e. communication overhead). Neither of these appeal. | As long as the ORB is a good CORBA citizen it should throw OBJECT_NOT_EXIST and (now) we catch that are translate it to rolled back. So hopefully that'll close some of the holes here too. But the test is still suspect :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204014#4204014 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204014

17 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: VFS cache as impl detail, to what extent

by alesj

"dimitris(a)jboss.org" wrote : I like it. Finally some positive VFS vibe from your side. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204007#4204007 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204007

17 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: VFS cache as impl detail, to what extent

by dimitris＠jboss.org

I like it. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204005#4204005 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204005

17 years, 2 months

1
0
0 / 0

[Design of JBoss Transaction Services] - Re: JTA/JTS thread disassociation semantics

by mark.little＠jboss.com

Yes, we can definitely cache the last known status in some cases, but it's not a complete solution as you outline. I agree that the test should be changed to cope with the uncertainties inherent when you add distribution in to this. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4203992#4203992 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4203992

17 years, 2 months

1
0
0 / 0

[Other JBoss Development Design] - Re: JBAS-6390, JBNAME-25, IPv6 support

by dimitris＠jboss.org

Committed also to Branch_5_x, thanks! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4203991#4203991 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4203991

17 years, 2 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 January 2009