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

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

by scott.stark＠jboss.org

The war ClassLoaderMetaData.isJ2seClassLoadingCompliance is false by default which is correct for wars, so in between the isAttachmentPresent call and checking ClassLoaderMetaData.isJ2seClassLoadingCompliance you should be correct for the standard wars. Is it the VFSClassLoaderScopingPolicy your working on? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4126323#4126323 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4126323

18 years, 2 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Removing hypersonic support

by jeffdelong

Customers tend to use either MySQL or Postgres. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4126322#4126322 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4126322

18 years, 2 months

1
0
0 / 0

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

by scott.stark＠jboss.org

"kabir.khan(a)jboss.com" wrote : | Basically, it needs to be able to understand that the war entries should be part of a sub domain with their own class pool. I only started using JBossWebMetaData locally today to figure out whether the sub unit is a jar or not, so please ignore the talk about that. isAttachmentPresent(String name) should fix that for me. | ... | I want to know if we are using j2seClassLoadingCompilance or not, to be able to construct the new ScopedClassPools. Ok, this should be defined in the org.jboss.deployers.structure.spi.classloading.ClassLoaderMetaData, but I need to check that its correct. There is a bit of a disconnect between the war class loading deployer still having these settings, a jboss-web.xml having these settings for the legacy LoaderRepository, and the war deployers also trying to use their defaults. Once we have the org.jboss.deployers.structure.spi.classloading.ClassLoaderMetaData consistently defining the class loader for a deployment unit, it seems that you should not care about wars specifically. The ScopedClassPools should be driven off the unit ClassLoaderMetaData.isJ2seClassLoadingCompliance() setting regardless of the deployment unit type. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4126318#4126318 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4126318

18 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: extra jars needed when deploying a Seam app into JBAS5 b

by scott.stark＠jboss.org

Its not the AnnotationMetaDataDeployer as it does not really do the scanning that is causing the problem. It already ignores classes for which it cannot obtain annotations from. The problem is with classes that were loadable in terms of class level annotations, but fail to be processed at the field/method level due to missing class dependencies. I have created a new jboss-metadata.jar snapshot that should ignore these types of errors. Can you try this jar out Charles? https://snapshots.jboss.org/maven2/org/jboss/jboss-metadata/1.0.0-SNAPSHO... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4126316#4126316 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4126316

18 years, 2 months

1
0
0 / 0

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

by kabir.khan＠jboss.com

"scott.stark(a)jboss.org" wrote : "kabir.khan(a)jboss.com" wrote : If deploying an ear, I need to find the war files. I think the precense of a JBossWebMetaData attachment is the best way to determine if we are a war? | | | Yes. What is special about wars for the aspect deployer? I'm still trying to understand how the JBossWebMetaData is coming into the picture and causing problems now, but not before the war class loader change. Note that you can ask about whether an attachment is present using its name as DeploymentUnit.isAttachmentPresent(Class type) is just a convenience method for isAttachmentPresent(type.getName()). | Basically, it needs to be able to understand that the war entries should be part of a sub domain with their own class pool. I only started using JBossWebMetaData locally today to figure out whether the sub unit is a jar or not, so please ignore the talk about that. isAttachmentPresent(String name) should fix that for me. "scott.stark(a)jboss.org" wrote : | "kabir.khan(a)jboss.com" wrote : | | Next, I need to check if the war classloader delegates to the parent or not. I will try looking for that info in the in ClassLoadingMetaData of the war's sub deployment. | Ok, this may not be in synch with the new org.jboss.deployers.structure.spi.classloading.ClassLoaderMetaData attachment. I'll have to check that. | | What is the code your working on here so I can understand what type of class loader processing your doing? | I want to know if we are using j2seClassLoadingCompilance or not, to be able to construct the new ScopedClassPools. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4126315#4126315 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4126315

18 years, 2 months

1
0
0 / 0

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

by scott.stark＠jboss.org

"kabir.khan(a)jboss.com" wrote : If deploying an ear, I need to find the war files. I think the precense of a JBossWebMetaData attachment is the best way to determine if we are a war? | Yes. What is special about wars for the aspect deployer? I'm still trying to understand how the JBossWebMetaData is coming into the picture and causing problems now, but not before the war class loader change. Note that you can ask about whether an attachment is present using its name as DeploymentUnit.isAttachmentPresent(Class type) is just a convenience method for isAttachmentPresent(type.getName()). "kabir.khan(a)jboss.com" wrote : | Next, I need to check if the war classloader delegates to the parent or not. I will try looking for that info in the in ClassLoadingMetaData of the war's sub deployment. Ok, this may not be in synch with the new org.jboss.deployers.structure.spi.classloading.ClassLoaderMetaData attachment. I'll have to check that. What is the code your working on here so I can understand what type of class loader processing your doing? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4126312#4126312 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4126312

18 years, 2 months

1
0
0 / 0

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

by kabir.khan＠jboss.com

If deploying an ear, I need to find the war files. I think the precense of a JBossWebMetaData attachment is the best way to determine if we are a war? Next, I need to check if the war classloader delegates to the parent or not. I will try looking for that info in the in ClassLoadingMetaData of the war's sub deployment. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4126308#4126308 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4126308

18 years, 2 months

1
0
0 / 0

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

by bytor99999

It also looks like for XA Datasources it is different too. XA connection properties shows as | xa-datasource-properties= | ManagedProperty{xa-datasource-properties, | metaType=ImmutableTableMetaType: | typeName=[java.util.Map] | rowType=[ImmutableCompositeMetaType{java.util.Map$Entry | items=[name=key type=java.lang.String], | [name=value type=java.lang.String]}] | indexNames=[key]} | But I guess we were expecting | ManagedProperty{(xa-)datasource-properties, | metaType=ImmutableCompositeMetaType{java.util.Map$Entry | items=[name=key type=java.lang.String], | [name=value type=java.lang.String]} | Thanks View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4126301#4126301 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4126301

18 years, 2 months

1
0
0 / 0

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

by scott.stark＠jboss.org

There are several ClassLoadingMetaData types. The org.jboss.metadata.web.jboss.ClassLoadingMetaData would only be set for a war with a jboss-web.xml that includes a scoped class loader metadata element. There is code in the AbstractWarDeployer to always set this if it was not obtained from the parsing layer, but this is now obsolete information. There is a DeploymentUnit org.jboss.deployers.structure.spi.classloading.ClassLoaderMetaData attachment that drives the new class loaders. Is that what your looking for? What do you need from ClassLoadingMetaData? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4126298#4126298 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4126298

18 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: DS stats

by bytor99999

We are looking for the following stats, which appear in the first section of ManagedProperties that you posted. "Total Connections" property="ConnectionCount" "Available Connections" property="AvailableConnectionCount" "Active Connections" property="InUseConnectionCount" "Connections Created" property="ConnectionCreatedCount" "Connections Destroyed" property="ConnectionDestroyedCount" I never saw them in the ManagedOperation instance while debugging. So it is interesting that sometimes you see them there through the tests. Thanks for letting us know. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4126296#4126296 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4126296

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