[Design of POJO Server] - Re: VFS Permissions - JBMICROCONT-149
by adrian@jboss.org
Unlike Ales I don't have a problem with making the default value
a system property as long as there is more fine grained control for each classloader.
But...
"anil.saldhana(a)jboss.com" wrote :
| DefaultClassLoaderSystem.java
| -------------------------------------
| public class DefaultClassLoaderSystem extends ClassLoaderSystem
| {
| @Override
| protected ClassLoaderDomain createDomain(String name)
| {
| return new ClassLoaderDomain(name);
| }
| }
|
| and so on.
|
|
There, there is no easy way to get to VFSClassloaderPolicy at the moment for configuration. If it was provided, then it would have been easier. :)
I'm amazed you could find one of the ways to override the ClassLoaderDomain
implementation, but then didn't find the method on the domain itself? :-)
| /**
| * Invoked before adding a classloader policy
| *
| * @param classLoader the classloader
| * @param policy the classloader policy
| */
| protected void beforeRegisterClassLoader(ClassLoader classLoader, ClassLoaderPolicy policy)
| {
| // nothing
| }
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4188517#4188517
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4188517
17 years, 5 months
[Design of POJO Server] - Re: VFS Permissions - JBMICROCONT-149
by anil.saldhana@jboss.com
"alesj" wrote :
| As you could probably also see, I've rolled back your CL changes as well.
| Using System property in such way w/o discussing it before is a huge no-no.
| If you really needed that you could either
| - make it true by default (as it is now)
| - created few new classes in jbossas: deployer + policy combination that sets that flag to true
|
AS5 today is booting with the VFSClassloader system via the system property? Then why don't you fix that (by making things injectable) first rather than preach here about using a system property (in fact the vfs project has a lot of system properties)? Here let me show you.
| conf/classloader.xml
|
| <!--
| The classloader implementation
| -->
| <bean name="ClassLoaderSystem" class="org.jboss.classloader.spi.ClassLoaderSystem">
| <classloader><null/></classloader>
| <constructor factoryClass="org.jboss.classloader.spi.ClassLoaderSystem" factoryMethod="getInstance"/>
| </bean>
|
|
Now let us look at the code.
|
| ClassLoaderSystem.java
| -----------------------------
| /** The class loading system builder */
| private static final ClassLoaderSystemBuilder builder = new ClassLoaderSystemBuilder();
|
| public static final ClassLoaderSystem getInstance()
| {
| SecurityManager sm = System.getSecurityManager();
| if (sm != null)
| sm.checkCreateClassLoader();
| return builder.get();
| }
|
|
| public class ClassLoaderSystemBuilder
| {
| /** The singleton */
| private static final ClassLoaderSystem singleton;
|
| static
| {
| singleton = AccessController.doPrivileged(new PrivilegedAction<ClassLoaderSystem>()
| {
| public ClassLoaderSystem run()
| {
| String className = System.getProperty(ClassLoaderSystem.class.getName(), DefaultClassLoaderSystem.class.getName());
| try
| {
| Class<?> clazz = Thread.currentThread().getContextClassLoader().loadClass(className);
| Object result = clazz.newInstance();
| return ClassLoaderSystem.class.cast(result);
| }
| catch (RuntimeException e)
| {
| throw e;
| }
| catch (Exception e)
| {
| throw new Error("Unexpected error loading ClassLoaderSystem " + className, e);
| }
| }
| });
|
| public static ClassLoaderSystem get()
| {
| return singleton;
| }
| }
|
|
| DefaultClassLoaderSystem.java
| -------------------------------------
| public class DefaultClassLoaderSystem extends ClassLoaderSystem
| {
| @Override
| protected ClassLoaderDomain createDomain(String name)
| {
| return new ClassLoaderDomain(name);
| }
| }
|
| and so on.
|
|
There, there is no easy way to get to VFSClassloaderPolicy at the moment for configuration. If it was provided, then it would have been easier. :)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4188506#4188506
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4188506
17 years, 5 months
[Design of POJO Server] - xml persistent format for attachments
by emuckenhuber
I created some simple tests trying to persists some metadata as xml with JAXB,
using ManagedConnectionFactoryDeploymentGroup, ServiceDeployment/ServiceMetaData and AbstractKernelDeployment/AbstractBeanMetaData
Baiscally for ManagedConnectionFactoryDeploymentGroup the problem is that the @XmlAdapter for the mbean just implements the unmarshal part.
So there is only ServiceMetaDataParser and nothing equivalent for the marshalling part. So the mbean would get lost :)
Similar for ServiceDeployment. We could maybe reuse the org.w3c.dom.Element information, although it would need to get updated with the information of the changed ManagedComponent.
So not sure if updating the element makes more sense than writing a counterpart of the parsing.
JAXB also does not like the annotated BeanMetaData for marshalling.
This ends up in a exception like this:
| com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 45 counts of IllegalAnnotationExceptions
| org.jboss.kernel.plugins.deployment.AbstractKernelDeployment#beanFactories has mutually exclusive annotations @javax.xml.bind.annotation.XmlElements and @javax.xml.bind.annotation.XmlAnyElement
| ...
| at org.jboss.kernel.plugins.deployment.AbstractKernelDeployment
| @XmlValue is not allowed on a class that derives another class.
| ...
|
Although i haven't really looked into that in more detail yet :)
So maybe we need different xml AttachmentSerializer for each metadata,
as the deployment descriptors are also parsed differently in the first place?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4188494#4188494
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4188494
17 years, 5 months
[Design of POJO Server] - Re: VFS Permissions - JBMICROCONT-149
by alesj
"anil.saldhana(a)jboss.com" wrote :
| I already had generated the constants. I was unable to put it back as I forgot before I slept and you rolled back.
I didn't rollback b/c of lack of constants.
I did it b/c it was wrong and the code actually is not useful --> needs to be in proper VFHandler.
Even the method signature didn't fit the needs. ;-)
As you could probably also see, I've rolled back your CL changes as well.
Using System property in such way w/o discussing it before is a huge no-no.
If you really needed that you could either
- make it true by default (as it is now)
- created few new classes in jbossas: deployer + policy combination that sets that flag to true
Dunno how you do it in security project, but I would really appreciate it
if in the future you discussed things before here on the forum.
Saving us both time. ;-)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4188491#4188491
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4188491
17 years, 5 months