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

[Design of JBoss Build System] - Re: Use of

by pgier

Yes, the mapping is there just to map to existing paths. So if this is a new dependency, I would prefer that you use the maven path and then you won't need any mapping configuration. Eventually, I would like to remove all the mapping configs and simplify the pom, but in the short term I just didn't want to risk breaking the build. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4156045#4156045 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4156045

17 years, 10 months

1
0
0 / 0

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

by bstansberry＠jboss.com

I brought it up because I have an annotation whose default is a system property and we were discussing another such case. I have a hard coded workaround for the 1st and don't like adding another. But it's not a high priority for me personally; the discussion just brought it to mind. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4156037#4156037 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4156037

17 years, 10 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: Ability to restart a Connect with SocketServerInvoker

by ron.sigal＠jboss.com

Hi Brian, I suppose the idea was that UnifiedInvoker wouldn't be sharing it's Connector/SocketServerInvoker with anyone else. Conceptually, I think you're right that an invocation handler shouldn't shut down its server. Of course, it's probably reasonable to think of UnifiedInvoker as a special case. It seems to me that there are two solutions. 1. Let UnifiedInvoker continue to shut down its Connector and restart the Connector before restarting UnifiedInvoker. 2. Remove | if(serverInvoker != null) | { | serverInvoker.stop(); | } | from UnifiedInvoker.stopService(). Either solution should eliminate the problem with restarting SocketServerInvoker. The first solution creates a new SocketServerInvoker, and the second reuses a running SocketServerInvoker. Since you're doing the testing, do you mind making the changes? -Ron View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4156036#4156036 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4156036

17 years, 10 months

1
0
0 / 0

[Design of JBoss Build System] - Use of

by bstansberry＠jboss.com

Is there any preference for using the "mapping" element in a thirdparty/pom.xml dependency element? My take on it is it's used to prevent breaking the legacy paths that are all over the build system and that for new additions it's better to just have the thirdparty structure mirror the maven repo structure. E.g. I'm adding the org.hibernate/hibernate-jbosscache2 jar while there's an existing hibernate-core: | <dependency> | <groupId>org.hibernate</groupId> | <artifactId>hibernate-core</artifactId> | <mapping> | <componentId>hibernate</componentId> | </mapping> | </dependency> | <dependency> | <groupId>org.hibernate</groupId> | <artifactId>hibernate-jbosscache2</artifactId> |  | </dependency> | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4156034#4156034 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4156034

17 years, 10 months

1
0
0 / 0

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

by david.lloyd＠jboss.com

This seems like a really cool feature - I'm sure I could make use of it in XNIO and Remoting - but is this something that can/should wait until after AS5.0 is released? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4156030#4156030 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4156030

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 : We just want to have a copy of that in tmp to be able to remove the original from deploy. You mean like this | 2008-06-05 17:27:02,828 DEBUG [org.jboss.deployers.plugins.deployers.DeployersImpl] (HDScanner) Undeploying vfszip:/C:/projects/jboss5/trunk/build/output/jboss-5.0.0.CR1/server/minimal/deploy/shutdown.sar | 2008-06-05 17:27:02,828 DEBUG [org.jboss.system.ServiceController] (HDScanner) stopping service: jboss.test:name=ExitOnShutdown | 2008-06-05 17:27:02,828 DEBUG [org.jboss.test.jmx.shutdown.ExitOnShutdown] (HDScanner) Stopping jboss.test:name=ExitOnShutdown | 2008-06-05 17:27:02,828 DEBUG [org.jboss.test.jmx.shutdown.ExitOnShutdown] (HDScanner) Stopped jboss.test:name=ExitOnShutdown | 2008-06-05 17:27:02,828 DEBUG [org.jboss.system.ServiceController] (HDScanner) destroying service: jboss.test:name=ExitOnShutdown | 2008-06-05 17:27:02,828 DEBUG [org.jboss.system.ServiceController] (HDScanner) removing service: jboss.test:name=ExitOnShutdown | You can call it magic. ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4156024#4156024 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4156024

17 years, 10 months

1
0
0 / 0

[Design of JBoss Portal] - Re: org.jboss.portal.portlet.container.PortletInitialization

by prabhat.jha＠jboss.com

Please look look at portletswap.com for the deployment descriptors that are needed for jsf portlet View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4156022#4156022 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4156022

17 years, 10 months

1
0
0 / 0

[Design of JBoss Portal] - org.jboss.portal.portlet.container.PortletInitializationExce

by michaelchan

Hi all, I am trying to port my own helloWorld jsf app to portlet. The app runs alright when stand alone but i get the error when trying to deploy as portlet org.jboss.portal.portlet.container.PortletInitializationException: Which part could be wrong? I changed the JSF libs to myface lib, and followed pretty much the JSF tutorial in JBoss portal docs... please help, thanks View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4156019#4156019 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4156019

17 years, 10 months

1
0
0 / 0

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

by scott.stark＠jboss.org

In general the annotation based metadata is not authoritative and should be overridden. Carlo has some examples of where it needs to be additively merged rather than the xml overriding annotations. One example of a problem I have seen is an annotation mappedName overriding a jboss descriptor jndi-name. That is incorrect. So what are the options? (addAll) - the "override" metadata is simply replaces the "original" metadata? (customizing) - the "override" metadata is merged with the "original" metadata with the override fields overriding the original? For the (customizing) behavior, this typically will need to be done recursively. Both override and original will have references metadata for example that needs to be merged down to the reference level. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4156010#4156010 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4156010

17 years, 10 months

1
0
0 / 0

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

by wolfc

This is the relevant part for interceptors: "EJB 3.0 12.8.2" wrote : The binding of interceptors to classes is additive. If interceptors are bound at the class-level and/or default-level as well as at the method-level, both class-level and/or default-level as well as method-level interceptors will apply. The deployment descriptor may be used to augment the interceptors and interceptor methods defined by means of annotations. When the deployment descriptor is used to augment the interceptors specified in annotations, the interceptor methods specified in the deployment descriptor will be invoked after those specified in annotations, according to the ordering specified in sections 12.3.1 and 12.4.1. The interceptor-order deployment descriptor element may be used to override this ordering. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4156007#4156007 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4156007

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