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

[Design the new POJO MicroContainer] - Re: Alternative vfs jar implementation

by dimitris＠jboss.org

How you treat a case of .e.g. a simple ejb .jar or a .sar without nested libraries. It's not nested and not exploded either. We just want to have a copy of that in tmp to be able to remove the original from deploy. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4156006#4156006 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4156006

17 years, 10 months

1
0
0 / 0

[Design of POJO Server] - Re: Replacing system properties in metadata

by scott.stark＠jboss.org

Right, I don't think Replaceable is sufficient. I think this should be dervived from the ManagementProperty annotation declaring a type of SystemPropertyMetaType (does not exist currently) so that a mgmt tool can show what property refs are in use as well as what those values resolve to for a given profile's/servers properties. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4156004#4156004 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4156004

17 years, 10 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Alternative vfs jar implementation

by alesj

"dimitris(a)jboss.org" wrote : Ales is telling me this is not only a VFS issue; the deployers will have to be changed as well. I don't know what exactly is required for that, but if we don't go that direction I feel we are just going cyrcles with this problem. No, deployers already have this. ;-) I was just trying to explain it to you, that I've made a little fix to handle this the right way - adding new VFSUtils api and a new ModificationType enum in deployers. I now diff between unpack (meant for nested archives only) and explode (mostly meant for top level archives, but could be used on nested as well == then it's the same as unpack). Why I want to diff the two - we should already be able to handle (read, scan, ...) top levels, so I don't really see the need to unpack them, except if you explicitly say so, and that is what I call explode. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4155994#4155994 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4155994

17 years, 10 months

1
0
0 / 0

[Design of EJB 3.0] - JBossMetaData merge/override rules

by alex.loubyansky＠jboss.com

There are at least two sources of metadata: annotations and xml. Whatever approach we choose to represent them, we have to define which information is added (i.e. overriding metadata complements the original) during the merge and which one is completely redefined by the overriding metadata. For example, in case of security, should the permissions from the XML (if present) replace the permissions defined with annotations completely or extend them? I think, in general, the answer may depend on the type of metadata in question? There maybe even a special annotation/xml element which would say how the merge should be done? Or maybe even result in a deployment error for something that must not be overriden? Anyway, let's define the defaults. I've been writing some tests for every metadata type. But I am still not sure about some of them and would like to clarify. In simple words for the following types what should be a complete replacement and what should be merged as "addAll()" overriding data with the same key (customizing). I added (addAll) where it seems to me it should be. >From JBossEnterpriseBeanMetaData - InvokerBindingsMetaData (allAll) - IORSecurityConfigMetaData - JBossEnvironmentRefsGroupMetaData (addAll?) - MethodAttributesMetaData (addAll) - AnnotationsMetaData - IgnoreDependencyMetaData (addAll) - PoolConfigMetaData (addAll) - JndiRefsMetaData (addAll) >From JBossSessionBeanMetaData - BusinessLocalsMetaData - BusinessRemotesMetaData - InitMethodsMetaData - RemoveMethodsMetaData - AroundInvokesMetaData - LifecycleCallbacksMetaData - LifecycleCallbacksMetaData - SecurityRoleRefsMetaData - List remoteBindings - ClusterConfigMetaData - PortComponent - SecurityIdentityMetaData - CacheConfigMetaData >From JBossEntityBeanMetaData - CMPFieldsMetaData (should it be ever overriden?) - QueriesMetaData (only cutomization of the existing) - CacheInvalidationConfigMetaData (customize existing) >From JBossMessageDrivenBeanMetaData - ActivationConfigMetaData (addAll) >From JBossConsumerBeanMetaData The following should probably be changed to Maps defining the keys for the types to make it easier identify the same metadata piece? private List messageProperties = null; private List producers = null; private List localProducers = null; >From JBossMetaData - RelationsMetaData (addAll) - LoaderRepositoryMetaData (addAll) - WebservicesMetaData (addAll) - JBossEnterpriseBeansMetaData (addAll) - ResourceManagersMetaData (addAll) - InvokerProxyBindingsMetaData (addAll) - ContainerConfigurationsMetaData (addAll) - InterceptorsMetaData - Map<String, RunAsIdentityMetaData> runAsIdentity >From JBossAssemblyDeploymentDescriptor - SecurityRolesMetaData - MethodPermissionsMetaData (addAll) - ContainerTransactionsMetaData (addAll) - InterceptorBindingsMetaData - MessageDestinationsMetaData - ExcludeListMetaData - ApplicationExceptionsMetaData In a number of types there are fields of primitive boolean types. It may make sense to switch to the wrapper to differentiate between the default and non-set value. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4155988#4155988 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4155988

17 years, 10 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: unit test code coverage

by jmesnil

"timfox" wrote : | But building with a different target (which is what I think you meant) is a good idea.. go for it :) ok, I'll create 2 targets: compile-core & compile-jms and refactored the classpaths for this 2 targets (e.g. j2ee jar is not required to compile-core) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4155971#4155971 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4155971

17 years, 10 months

1
0
0 / 0

[Design of POJO Server] - Re: Replacing system properties in metadata

by bstansberry＠jboss.com

Adrian and I both opened threads on the same general topic. :) In the other one at http://www.jboss.com/index.html?module=bb&op=viewtopic&t=136807 I think Scott is driving at a need to provide visibility to the raw value as well; i.e. make sure the raw value is visible to services like mgmt tools that want it. Will this change to MetaDataRetrievalToMetaDataBridge preclude that? If so we should probably defer doing this until we have a solution to that problem. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4155968#4155968 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4155968

17 years, 10 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Alternative vfs jar implementation

by dimitris＠jboss.org

I did some local testing with the latest VFS Beta13 and no-matter what combination of flags I use, I cannot get to the point of getting the test with shutdown.sar behave correctly. The other thing is I don't see noticable differences in the performance of the various implementations. Probably the reaper impl is a little bit faster. My conclusion is we should really go for the good old tested mode of copying jars to tmp and loading them from there. Ales is telling me this is not only a VFS issue; the deployers will have to be changed as well. I don't know what exactly is required for that, but if we don't go that direction I feel we are just going cyrcles with this problem. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4155965#4155965 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4155965

17 years, 10 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Some thread safety issues with AIO callbacks

by timfox

I have fixed some thread safety issues with various AIO callback classes, both in the test suite and core. In most of these classes the callback attributes weren't being sufficiently protected by access by more than one thread. I have corrected this, also I removed unused code, and some other changes like making fields private and final etc. Please! No package protected fields unless there is a good reason to. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4155955#4155955 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4155955

17 years, 10 months

1
0
0 / 0

[Deployers on JBoss (Deployers/JBoss)] - Classloader issue when migrating application from tomcat to

by ashishraik11

Hi, I am migrating application from Tomcat to jboss-4.2.2.GA, I did the configuration but still I am getting NoClassDefFoundException, same thing is working properly with Tomcat. I gone through the document for jboss configuration, I did that also still, I am getting NoClassDefFoundException. I also did one more thing I used UnifiedClassLoader3 is given as below for this I am getting ClassCastException. UnifiedClassLoader3 actualClassLoader = (UnifiedClassLoader3) Thread.currentThread().getContextClassLoader(); actualClassLoader.addURL(new URL(System.getProperty("jboss.server.config.url")+ "linkmanager/models/services/")); cls = actualClassLoader.loadClass(annotationclass, true); After doing all this stuff still this problem is not resolved from last one week. Can any body help me to resolve this problem of classloader. Thanks in Advance Ashish Rai View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4155946#4155946 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4155946

17 years, 10 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: unit test code coverage

by timfox

Well the code is already split in terms of packages. But building with a different target (which is what I think you meant) is a good idea.. go for it :) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4155914#4155914 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4155914

17 years, 10 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 June 2008