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

[Design of POJO Server] - Re: Instance annotations from Object Models

by adrian＠jboss.org

"scott.stark(a)jboss.org" wrote : The way I see it, the Ejb3DescriptorHandler should not be using the AnnotationRepository, nor its MetaDataRepository replacement. Rather, the annotations should be another source of data for the org.jboss.metadata.* pojos. | | There are two ways this can be done. One would be to create another merged view similar to how the standard metadata is merged into the jboss metadata. Defining a merge(AnnotatedElement) api to map the annotations onto the jboss metadata view would be needed. | | The second would be to create a separate wrapped view similar to how the standardjboss.xml is handled. The wrapped view would be MetaDataRepository aware and look to it for the annotation based metdata. This is the approach I think is cleanest. | That doesn't solve the problem. The issue is making the xml look like annotations such that EJB3's AOP confgiguration (which works off annotations to enable adivces) can see the configuraiton from the xml. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4101776#4101776 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4101776

18 years, 5 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Generalizing supply/demand

by adrian＠jboss.org

"scott.stark(a)jboss.org" wrote : | It can only demand whatever with legacy 'demand' element. | I have no objections with moving demand/supply notion to our dependency module. Although this bloats simple 'state machine' impl in dependency. If supply/demand are to be mc bean specific it simply cannot be used as a cross-container mechanism. It seems like this can be replaced with a dependency on an alias, in which case, that is how the mc supply/demand should be implemented. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4101771#4101771 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4101771

18 years, 5 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: remoting streams

by david.lloyd＠jboss.com

The Remoting 3 prototype has a generic streaming mechanism that's pretty similar to what you propose. Basically any object that is recognized as a stream type is replaced with a proxy that moves the data over the wire. This way you can create custom stream types beyond the predefined type, and a single request can contain multiple streams; data can be pushed from server to client (e.g. pass an OutputStream as part of the request), or pulled from client to server (e.g. pass an InputStream) The predefined stream types are defined here: http://anonsvn.jboss.org/repos/sandbox/david.lloyd/remoting3/api-proto/sr... Also, Reader/Writer and Input/OutputStreams will be supported by default. Please have a look over this material and let me know if there are any key features that are missing... specifically if you have any thoughts about things like flow control, or any insights based on your implementation. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4101746#4101746 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4101746

18 years, 5 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: Merging PortComponentRefs

by thomas.diesler＠jboss.com

JBossPortComponentRef should extend PortComponentRef i.e. it should not have a SEI property on its own. The reason this is duplicated in the the jboss dtd is for identification purposes View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4101706#4101706 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4101706

18 years, 5 months

1
0
0 / 0

[Design of JBoss Portal] - Re: Changing Layout and Regions

by PMN

I am referring to getting a definition of a layout and a strategy for a "widget" to display, you may have a different strategy in different mode or a fit to size strategy. I am using the term widget to unerdline another point of choosing the correct granularity to decide whether or not a widget fit in a portlet or a portlet display several widgets. There are 4 questions: what is a layout, choosing a layout, distribute widgets and where to implement a strategy. I found the YUI approach of a layout very simple and fluid. It's what they call "grid". Put it with my abstract words, it 's controlling by width. The document generally control the total width (define header, main, footer and a left or right margin), a grid is a recursive definition of blocks ("lines") divided in columns. Of course you can customize things but they provide pattern of divisions : 1//2, 1/2 or 1/3,1/3,1/3 or 1/3,2/3 or 2/3,1/3 or 1/4,3/4 or 3/4,1/4. It's all controlled by CSS and play it simple and easy. A layout stay a jsp file as defined by Portal and to associate a portlet instance to a block, simply put the <p:region> tag into it. Now, because it is controlled by width you run into this problem when a portlet renders differently in different modes. You need to have a strategy as choosing one size for all mode is inconvenient. Actually it is already what JBP is doing in the layouts.xml file when the URI has the attribute "state=maximized" to associate a layout to a window state. Where to control the layout should be in the event listener : when a portlet turns into EDIT mode change layout to give it more space if needed. If changing layout is necessary, it is not sufficient, you also need to put it on spot. Actually that what JBP does with the region "maximized" in the maximized.jsp layout. Actually, with no new concept and minimal changes you can do a lot and let it all to the application to implement a strategy. Is that better? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4101701#4101701 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4101701

18 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JMX Operations to expose to clients in JBM 2.0

by ataylor

I think thats a good idea, it also means that the user never needs to edit the jboss-beans.xml config file, just the configuration View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4101688#4101688 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4101688

18 years, 5 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Plug-able default JNDI binding policy

by wolfc

Create a new artifact in projects/ejb3 so we can import one component into both 4.2 and 5. For the xml I would to see an expression in the likes of: ${earName}/${deploymentName}/${beanName}/${interfaceType} I don't want a requirement to create new classes when configuring xml stuff. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4101681#4101681 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4101681

18 years, 5 months

1
0
0 / 0

[Design of EJB 3.0] - Re: New Build Artifact - EJB3 External API

by wolfc

The jboss-ejb3-ext-api.jar artifact must come from projects/ejb3, not from AS trunk. This ensures isolation from the other code and a separate release cycle (so we can freeze it). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4101678#4101678 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4101678

18 years, 5 months

1
0
0 / 0

[Design of JBoss Portal] - Re: Changing Layout and Regions

by julien＠jboss.com

Could you give an example of your idea, so we can better understand ? it seems a bit abstract in what you describe thanks View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4101638#4101638 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4101638

18 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: Instance annotations from Object Models

by scott.stark＠jboss.org

The way I see it, the Ejb3DescriptorHandler should not be using the AnnotationRepository, nor its MetaDataRepository replacement. Rather, the annotations should be another source of data for the org.jboss.metadata.* pojos. There are two ways this can be done. One would be to create another merged view similar to how the standard metadata is merged into the jboss metadata. Defining a merge(AnnotatedElement) api to map the annotations onto the jboss metadata view would be needed. The second would be to create a separate wrapped view similar to how the standardjboss.xml is handled. The wrapped view would be MetaDataRepository aware and look to it for the annotation based metdata. This is the approach I think is cleanest. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4101613#4101613 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4101613

18 years, 5 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 November 2007