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

[Design of Messaging on JBoss (Messaging/JBoss)] - moving SecurityAspect to be an interceptor

by ataylor

It makes sense to remove the handling of security from the endpoints themselves and handle them transparently to make things cleaner. Currently, however, the username and password are only available on the ServerConnectionEndpoint. One way to solve this is to associate a user with a connection on the client side and pass it with the Packet on send. Does anyone have any thoughts on this? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4127322#4127322 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4127322

18 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: Another startup time regression

by dimitris＠jboss.org

I took a few threadumps and it looks to be processing annotations. at java.lang.ClassLoader.loadClass(ClassLoader.java:251) | at org.jboss.aop.Advisor.loadAnnotationClass(Advisor.java:671) | at org.jboss.aop.Advisor.hasAnnotation(Advisor.java:511) | Kabir will you take a look? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4127320#4127320 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4127320

18 years, 2 months

1
0
0 / 0

[Design of EJB 3.0] - Versioning Conventions

by ALRubinger

How will we proceed with versioning conventions in the EJB3 Component? Originally Carlo had set up a relationship between RC number and release such that RC12 == 0.12.0 for each project comprising the EJB3 component. However, this becomes invalidated as we've added modules to the project which may or may not change with each subsequent release. I'll propose a format of X.Y-SNAPSHOT for trunk, to be named X.Y in a branch (in preparation for tagging) and X.Y.Z for each release, where the following applies: X = Major version; rewrites, no guarantee of backward-compatibility Y = Minor version; typically each release with new features or API Z = Patch version; small changes made as release is prepared We may then build a matrix in which EJB3 Release N consists of 0.3.0 ext-api. 0.1.3 core, etc, eg. I'm not married to the above, but I'd like some sort of convention; things are getting messy in there. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4127262#4127262 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4127262

18 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: Datasource Connection Properties using CollectionMetaTyp

by scott.stark＠jboss.org

This is now working in trunk. See the use of the ProfileServiceUnitTestCase.compositeValueMap for creating the CompositeValue from a Map(String,String). This needs to be moved into the mc metatype MetaValueFactory to allow one to create the CompositeValue directly from the map instance. I'm not sure if your using the MetaValueFactory currently. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4127261#4127261 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4127261

18 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - InstanceClassFactory needs to be split up

by scott.stark＠jboss.org

I believe the InstanceClassFactory should be split up into a base ManagedPropertyMarshaller: | public interface ManagedPropertyMarshaller<T extends Serializable> | { | /** | * Get the value from object. | * | * @param beanInfo managed object's bean info | * @param property managed property | * @param attachment attachment | * @return meta value | */ | MetaValue getValue(BeanInfo beanInfo, ManagedProperty property, T attachment); | | /** | * Set the value to object. | * | * @param beanInfo managed object's bean info | * @param property managed property | * @param attachment attachment | * @param value meta value | */ | void setValue(BeanInfo beanInfo, ManagedProperty property, T attachment, MetaValue value); | } | The InstanceClassFactory getManagedObjectClass method: | public interface InstanceClassFactory<T extends Serializable> extends ManagedPropertyMarshaller<T> | { | /** | * Return the Class that represents the root ManagedObject to scan | * for management object related annotations. | * | * @param attachment - the instance a ManagedObject is to be created for. | * @return the Class that represents the root ManagedObject. | * @throws ClassNotFoundException if MO class not found | */ | Class<? extends Serializable> getManagedObjectClass(T attachment) throws ClassNotFoundException; | } | and a separate RuntimeComponentName: | public interface RuntimeComponentName<T extends Serializable> | { | /** | * Get the runtime component name. | * | * @param beanInfo managed object's bean info | * @param property managed property | * @param attachment attachment | * @param value original value | * @return meta value | */ | Object getComponentName(BeanInfo beanInfo, ManagedProperty property, T attachment, MetaValue value); | } | The ManagementProperty could then be updated to have specific marshallers declared: | @Target({ElementType.METHOD}) | @Retention(RetentionPolicy.RUNTIME) | public @interface ManagementProperty | { | ... | /** The getValue/setValue marshaller factory */ | Class<? extends InstanceClassFactory> marshallerFactory() default NULL_MARSHALLER_FACTORY.class; | } | Right now its cumbersome to just override marshalling for a property due to the extra behaviors of the InstanceClassFactory. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4127238#4127238 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4127238

18 years, 2 months

1
0
0 / 0

[Design of JBossCache] - Re: Amazon S3 cache loader

by genman

I figured out how to optimize it, though there are race conditions when sharing caches, but the whole thing is full of potential race conditions. :-) I optimized put() by creating a cheap cache of all the dummy nodes created by previous put() operations. This seemed to work well enough to pass all the CacheLoader tests. By the way, to test the darn thing, you have to have an Amazon S3 account. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4127237#4127237 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4127237

18 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: Facelets scanning for .taglib.xml is broken in trunk

by scott.stark＠jboss.org

If JarFile supported a JarInputStream I would look at support a JarURLConnection from the handler, but you have to have a path to a file as far as I can see. I would say hacking the facelets code to create patch Classpath to try to use a JarInputStream to find the taglib descriptiors is the best approach. There will be a patched facelets jars required, and we give back the patch. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4127236#4127236 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4127236

18 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: Facelets scanning for .taglib.xml is broken in trunk

by alesj

"scott.stark(a)jboss.org" wrote : | This code should be using JarInputStream(InputStream in) rather than a JarFile so that the InputStream can be obtained from an arbitrary URL. JarFile is the least flexible api to be using. | What's to do here? Have home brew of this on top of VFS? And push for change of making this search either pluggable or using JIS? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4127234#4127234 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4127234

18 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: FIELD granularity web session replication tests

by bstansberry＠jboss.com

Enjoying talking to myself. ;) This looks like another variant on the problem discussed at http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4126757#4126757 . FieldBasedSessionPassivationTestCase.testRedeploy() tests redeploying a war and still being able to access sessions. The sessions are passivated to disk on undeploy and after redeploy can be activated. Problem is JBC isn't handling the classloader very well during activation. It has logic to determine the correct classloader to use for deserialization based on the FQN of the node being deserialized. But that is broken in the case of deserializing passivated nodes. The effect is that JBC is using the cache's classloader to deserialize rather than the TCCL. This results in hitting the internal JVM caching problem Adrian was talking about on the other thread. I don't really want to support retrieving sessions from disk following a cluster restart anyway, so this test is testing something that won't exist in CR1. But I don't want to disable the test now since it has highlighted an important problem. I'll see if I can rearrange how test execution happens so this failure doesn't cause 30+ other tests to fail -- one failure is enough. I'll add a test to the JBC testsuite for the underlying issue, and for CR1 will add a couple general classloading tests to the AS to test what happens when the first usage of a type following a redeploy is via deserialization. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4127222#4127222 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4127222

18 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: Facelets scanning for .taglib.xml is broken in trunk

by scott.stark＠jboss.org

"alesj" wrote : | But why this worked before, with VFS and the new CL both already being used. | Why it stopped with your war CL changes? | I would guess because tomcat was rebuilding the URLClassLoader classpath, perhaps using the extracted jar so that they were simple file urls to the jars. This code should be using JarInputStream(InputStream in) rather than a JarFile so that the InputStream can be obtained from an arbitrary URL. JarFile is the least flexible api to be using. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4127199#4127199 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4127199

18 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 February 2008