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

[Design of POJO Server] - Leaking annotation API

by wolfc

I've got a nice API leakage: The @Cache annotation (which should be in jboss-ejb3-ext-api) package org.jboss.annotation.ejb; | public @interface Cache | { | Class<? extends StatefulCache> value(); | } is using StatefulCache interface (deprecated until further notice), package org.jboss.ejb3.cache; | public interface StatefulCache extends Cache<StatefulBeanContext> | { | ... | } which extends Cache from jboss-ejb3-cache (will probably become jboss-ejb3-cache-spi), which is bound on StatefulBeanContext from the ejb3 code / module. The @Cache annotation is used by a bean developer to specify the cache strategy: @Cache(org.jboss.ejb3.cache.impl.NoPassivationCache) 1. I would like to keep the limit on the annotation, it is meant to detect problems compile time; 2. From ejb3 code perspective I want to use getAnnotation(Cache.class).value() without a type cast. A. How can we prevent such a leak? B. Where should I put NoPassivationCache? Note that there is no hard dependency from core to this class (it's configuration).. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4094740#4094740 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4094740

18 years, 6 months

1
0
0 / 0

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

by scott.stark＠jboss.org

Right, I wanted @XmlElementWrapper to unwrap the module element and not have a wrapping Module class. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4094735#4094735 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4094735

18 years, 6 months

1
0
0 / 0

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

by alex.loubyansky＠jboss.com

Yes, that would work. I was trying to avoid Module as a wrapping class since this is what I think Scott wanted to have at the end. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4094727#4094727 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4094727

18 years, 6 months

1
0
0 / 0

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

by jason.greene＠jboss.com

Ah, I see you dont want a nested maxOccurs="unbounded". So is this what you want? | @XmlAccessorType(XmlAccessType.FIELD) | @XmlType(name = "application") | public class Foo { | @XmlElement(required = true) | public List<Module> module; | | @XmlAccessorType(XmlAccessType.FIELD) | @XmlType(name = "") | public static class Module { | @XmlElements({ | @XmlElement(name="connector", type=Connector.class), | @XmlElement(name="java", type=Java.class) | }) | public Component component; | | @XmlElement(name="alt-dd") | public String altDD; | } | | public static interface Component {} | public static class Connector implements Component | { | } | | public static class Java implements Component | { | } | } | Or you could also do this: | XmlAccessorType(XmlAccessType.FIELD) | @XmlType(name = "application") | public class Foo { | @XmlElement(required = true) | public List<Module> module; | | @XmlAccessorType(XmlAccessType.FIELD) | @XmlType(name = "") | public static class Module { | @XmlElement(name="java") | public Java java; | | @XmlElement(name="connector") | public Connector connector; | | @XmlElement(name="alt-dd") | public String altDD; | } | | public static class Connector | { | } | | public static class Java | { | } | } | Also, why not just use xjc generated model? -Jason View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4094724#4094724 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4094724

18 years, 6 months

1
0
0 / 0

[Deployers on JBoss (Deployers/JBoss)] - Re: JBossEjbParsingDeployer

by adrian＠jboss.org

I think you'll find the problem comes from the namespace. JBossXB returns null when it doesn't recognise the root element. It is expecting a root element of: {jboss-namespace}:jboss but since it is using the dtd, it is actually getting {}:jboss i.e. no namspace. JBossXB should be fixed generically to throw a message like :jboss is not a root element {jboss-namespace}:jboss but equally, JBossXB should be able to "fixup" the namespace for the case when one isn't provided if you know upfront what the namespace should be. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4094716#4094716 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4094716

18 years, 6 months

1
0
0 / 0

[Deployers on JBoss (Deployers/JBoss)] - Re: JBossEjbParsingDeployer

by wolfc

It's trying to parse the dtd specified in standardjboss.xml. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4094709#4094709 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4094709

18 years, 6 months

1
0
0 / 0

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

by alesj

Got them all running. Commiting the changes. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4094693#4094693 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4094693

18 years, 6 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: Thoughts about productivity

by alessio.soldano＠jboss.com

In particular concerning the samples, the strategy I'm think about is to provide customers with some real world usecases. Each of them is going to have its own scenario. Then we'll propose you reliable implementations leveraging the most suitable jbossws features and discussing the choices we take for the key points of each usecase. As said, soon you'll have the opportunity to choose the usecases you think are the most interesting; however if everybody want to start describing its own enterprise usecase/scenario... we'll be happy to consider that too. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4094685#4094685 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4094685

18 years, 6 months

1
0
0 / 0

[Design of JBoss Web Services] - Thoughts about productivity

by alessio.soldano＠jboss.com

Thanks to years of work the JBossWS project is mature enought to compare with the major webservice stacks all around. Constant development is required to implement WS-* standards, to support the integration within the JBoss enterprise products and so on. Moreover webservices should play a major part in the Service Oriented Architecture we're trasforming the customers' business to. For this reasons, apart from continuosly developing and enhancing our implementation and the integration layers we actually provide, it's time to reflect upon the real JBossWS users' needings, in terms of their productivity. Are they making the most of our project? what they miss in order to do that? Considering the whole webservice technology is not so trivial, our efforts should go in the direction of helping users through a product that easily address their issues, saving their time. We are required to supply customers with reliable solutions that can nevertheless be easily achieved and finally brought to a production environment. In short: what should we do to make the whole ws experience easier? I'm currently thinking about how this is going to be obtained; for sure, considering our target, we are going to base our productivity strategy on the real world lifecycle of a webservice application. This way we should cope with most of the issues ws users have to deal with, from the technology choices before the implementation, to the testing and all the issues concerning the productization of a service / service client. This means that we plan to organize our productivity efforts into five level ("WS Culture", "Start from scratch", "Development", "Transition / staging" and "Production"). Each of them is going to require different actions, including documentation improvement, creation of new tools, more and better samples and most probably some IDE integration efforts. I'll start one thread on this forum for each level, explaining what we think could be useful to do. Since there is going to be some days between this brainstorming phase and the actual definition of work, every comment, thought, etc from the community and from related projects' team on every thread could be useful. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4094684#4094684 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4094684

18 years, 6 months

1
0
0 / 0

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

by alesj

"alesj" wrote : And the good thing is that the usage of this method is minimal - 1 existing case + my new one. | The tests disagree. More then one failing. :-) I'll try to fix them. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4094672#4094672 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4094672

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