October 2007 - jboss-dev-forums - Jboss List Archives

[Design of JBossXB] - Re: @XmlElementWrapper/@XmlElements

by alex.loubyansky＠jboss.com

Actually the last approach is wrong. The adapter on ModuleHolder will make Module dictate the schema structure. That's pointless. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4094633#4094633 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4094633

18 years, 6 months

1
0
0 / 0

[Design the new POJO MicroContainer] - TypeInfo.newArrayInstance problems

by alesj

I'm having problems instantiating char array via TypeInfo.newArrayInstance. I get a CCE, when trying to cast char[] into Object[]. Is this expected? :-) Or is there a workaround or should this be fixed? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4094630#4094630 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4094630

18 years, 6 months

1
0
0 / 0

[Design of JBossXB] - Re: @XmlElementWrapper/@XmlElements

by alex.loubyansky＠jboss.com

This should be closer to what we would like to have @XmlRootElement | public static class Application | { | private List<Module> modules; | | public void setModules(List<Module> modules) | { | this.modules = modules; | } | | @XmlElement(name="module", type=ModuleHolder.class) | public List<Module> getModules() | { | return modules; | } | } | | public static class ModuleAdapter extends XmlAdapter<ModuleHolder, Module> | { | @Override | public ModuleHolder marshal(Module arg0) throws Exception | { | // TODO Auto-generated method stub | return null; | } | | @Override | public Module unmarshal(ModuleHolder arg0) throws Exception | { | return arg0.getModule(); | } | } | | @XmlJavaTypeAdapter(value = ModuleAdapter.class) | public static class ModuleHolder | { | private Module module; | | public void setModule(Module module) | { | this.module = module; | } | | @XmlTransient | public Module getModule() | { | return module; | } | | public void setConnector(ConnectorModule module) | { | this.module = module; | } | | public ConnectorModule getConnector() | { | return (ConnectorModule) module; | } | | | public void setEjb(EjbModule module) | { | this.module = module; | } | | public EjbModule getEjb() | { | return (EjbModule) module; | } | | public void setJava(JavaModule module) | { | this.module = module; | } | | public JavaModule getJava() | { | return (JavaModule) module; | } | } | | public static abstract class Module | { | private String value; | | public void setValue(String value) | { | this.value = value; | } | | @XmlValue | public String getValue() | { | return value; | } | } | | public static class ConnectorModule extends Module | { | } | | public static class EjbModule extends Module | { | } | | public static class JavaModule extends Module | { | } But there is an issue... currently it applies the adapter to the collection of modules as well as to the each module separately. I am looking into it. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4094623#4094623 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4094623

18 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: Scoped domain with java2ParentDelegation=false loads cla

by kabir.khan＠jboss.com

lol I did not see your reply View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4094621#4094621 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4094621

18 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: Scoped domain with java2ParentDelegation=false loads cla

by kabir.khan＠jboss.com

The following modification helps | Index: C:/cygwin/home/Kabir/sourcecontrol/jboss-head/system-jmx/src/main/org/jboss/system/deployers/HackClassloaderMetaDataDeployer.java | =================================================================== | --- C:/cygwin/home/Kabir/sourcecontrol/jboss-head/system-jmx/src/main/org/jboss/system/deployers/HackClassloaderMetaDataDeployer.java (revision 66088) | +++ C:/cygwin/home/Kabir/sourcecontrol/jboss-head/system-jmx/src/main/org/jboss/system/deployers/HackClassloaderMetaDataDeployer.java (working copy) | @@ -32,6 +32,7 @@ | import org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer; | import org.jboss.deployers.structure.spi.DeploymentUnit; | import org.jboss.deployers.structure.spi.classloading.ClassLoaderMetaData; | +import org.jboss.deployers.structure.spi.classloading.ExportAll; | import org.jboss.mx.loading.LoaderRepositoryFactory.LoaderRepositoryConfig; | import org.jboss.system.metadata.ServiceDeployment; | | @@ -101,6 +102,7 @@ | } | boolean useParentFirst = Boolean.valueOf(java2ParentDelegation).booleanValue(); | metaData.setJ2seClassLoadingCompliance(useParentFirst); | + metaData.setExportAll(ExportAll.NON_EMPTY); | | unit.addAttachment(ClassLoaderMetaData.class, metaData); | } | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4094620#4094620 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4094620

18 years, 6 months

1
0
0 / 0

[Design of JBossXB] - Re: @XmlElementWrapper/@XmlElements

by jason.greene＠jboss.com

"scott.stark(a)jboss.org" wrote : So how would an application.xml module element have to be handled? It should be something like this, but the schema for the wrapping module element has an unbounded max: | You need to introduce another type in JAXB to get both nesting levels to be unbounded. Like this (public fields used for simplicity): | XmlAccessorType(XmlAccessType.FIELD) | @XmlType(name = "Foo") | public class Foo { | @XmlElement(required = true) | public List<Foo.Bar> bar; | | @XmlAccessorType(XmlAccessType.FIELD) | @XmlType(name = "") | public static class Bar { | @XmlElements({ | @XmlElement(name="A", type=Integer.class), | @XmlElement(name="B", type=Float.class) | }) | public List items; | } | } | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4094615#4094615 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4094615

18 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: So what does unification mean for the ejb containers

by wolfc

"alex.loubyansky(a)jboss.com" wrote : Also currently jboss_5_0.xsd has http://java.sun.com/xml/ns/javaee as the target namespace which I think should be changed to a JBoss one. I've got a first draft of a new jboss_5_0.xsd in jboss-metadata. I'm not yet happy with: <?xml version="1.0"?> | <jboss | version="3.0" | xmlns="http://www.jboss.com/xml/ns/javaee" | xmlns:javaee="http://java.sun.com/xml/ns/javaee" | xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" | xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee | http://www.jboss.org/j2ee/schema/jboss_5_0.xsd | http://java.sun.com/xml/ns/javaee | http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd"> | <enterprise-beans> | <session> | <javaee:ejb-name>StatefulOverrideBean</javaee:ejb-name> | <jndi-name>StatefulOverride</jndi-name> | </session> | </enterprise-beans> | </jboss> Either I take ejb-nameType into jboss namespace or convince everybody that this is the way. After that is resolved, I'll commit. Note that the unit tests in jboss-metadata did not pick this up. I found out in trunk that stuff was going haywire. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4094610#4094610 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4094610

18 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: Scoped domain with java2ParentDelegation=false loads cla

by adrian＠jboss.org

The problem is in the hack class: jboss-head/system-jmx/src/main/org/jboss/system/deployers/HackClassloaderMetaDataDeployer.java When it creates the ClassLoaderMetaData from the old loader repository config, it should be specifying exportAll=ExportAll.NON_EMPTY and importAll=true for backwards compatibility. I've fixed this in head if you do an svn update of system-jmx. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4094604#4094604 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4094604

18 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: Scoped domain with java2ParentDelegation=false loads cla

by kabir.khan＠jboss.com

The underlying policy when registering a loader with the DEFAULT domain has -exportAll=ExportAll -exportedPackages contain the packages exported (probably from some scan?) The underlying policy when registering a loader with the scoped domain has -exportAll=null -exportedPackages is null I think this is the problem rather than being able to turn off blacklisting. The resources from the scoped domain are being ignored View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4094591#4094591 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4094591

18 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: Scoped domain with java2ParentDelegation=false loads cla

by adrian＠jboss.org

Ok, your problem looks to be that your domain doesn't have any classloaders: | No classloaders in this domain (the null) | | 2007-10-12 11:33:46,015 TRACE [org.jboss.classloader.spi.base.BaseClassLoaderDomain] ClassLoaderDoma | in@11b3435{aop.loading:loader=scopedextender1} trying to get resource org/jboss/test/aop/scopedexten | der/blah.txt from all exports null | | So load from parent | | 2007-10-12 11:34:10,906 TRACE [org.jboss.classloader.spi.ClassLoaderDomain] ClassLoaderDomain@11b343 | 5{aop.loading:loader=scopedextender1} org/jboss/test/aop/scopedextender/blah.txt matches parent afte | rFilter=<EVERYTHING> | | The parent has a classloader. | | 2007-10-12 11:34:10,921 TRACE [org.jboss.classloader.spi.base.BaseClassLoaderDomain] ClassLoaderDoma | in@1f21056{<DEFAULT>} trying to get resource org/jboss/test/aop/scopedextender/blah.txt from all exports [VFSClassLoader | Policy@c1a0a6] | So the question is why is there no classloader policies in aop.loading:loader=scopedextender1 You'll need to look at the deployment trace logging to see whether (and when) the classloader gets added to the domain or whether it is getting added to the wrong domain. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4094588#4094588 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4094588

18 years, 6 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 October 2007