April 2010 - jboss-dev-forums - Jboss List Archives

Re: [jboss-dev-forums] [JCA Development] - JcaXAResourceRecovery

by Jesper Pedersen

Jesper Pedersen [http://community.jboss.org/people/jesper.pedersen] replied to the discussion "JcaXAResourceRecovery" To view the discussion, visit: http://community.jboss.org/message/536131#536131 -------------------------------------------------------------- Jonathan, the addXAResourceRecovery() / removeXAResourceRecovery() methods are not exposed through JMX on jboss:service=TransactionManager. Could you add those ? -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/536131#536131] Start a new discussion in JCA Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

16 years

1
0
0 / 0

[Management Development] - To scope or not to scope (domain.xml)

by Jason Greene

Jason Greene [http://community.jboss.org/people/jason.greene%40jboss.com] created the discussion "To scope or not to scope (domain.xml)" To view the discussion, visit: http://community.jboss.org/message/536128#536128 -------------------------------------------------------------- In the past we talked about allowing resources to be defined, following a normal scoping mechanism, at the domain, cluster, or node level. An alternative approach would be to introduce a more limited notion of a homogenous group (1..many servers) which is the only location that things like resource definitions can occur. Creating server specific properties would require creating a new group definition. Clustering could even be viewed as a property of the homogenous group. The only issue is that some settings truly require scoping (like jvm parameters, sys properties, etc), so there would have to be special behavior there. This would give us something like: <domain> <group name="Production"> <clustered-service>.....</clustered-service> <resource name="Production DB"> .... </group> <server name="MyServer" group="Production"> <jvm maxMemory="..." /> </server> </domain> -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/536128#536128] Start a new discussion in Management Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

16 years

1
0
0 / 0

Re: [jboss-dev-forums] [Management Development] - domain.xml work

by Brian Stansberry

Brian Stansberry [http://community.jboss.org/people/bstansberry%40jboss.com] replied to the discussion "domain.xml work" To view the discussion, visit: http://community.jboss.org/message/536126#536126 -------------------------------------------------------------- The SBM case is an odd one; I basically used the MC schema to generate a bunch configuration pojos. So most of the injection there ends up just being injection of a configuration pojo. There is a JIRA to write a proper schema for the configuration stuff, which would end up as part of the domain.xml schema, but yeah, I could easily see it going away. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/536126#536126] Start a new discussion in Management Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

16 years

1
0
0 / 0

Re: [jboss-dev-forums] [Management Development] - domain.xml work

by Brian Stansberry

Brian Stansberry [http://community.jboss.org/people/bstansberry%40jboss.com] replied to the discussion "domain.xml work" To view the discussion, visit: http://community.jboss.org/message/536124#536124 -------------------------------------------------------------- > Jason Greene wrote: > > > Scott Stark wrote: > > > > I'm thinking that the profileservice ManagedComponent api is no longer relevant for our discussion. The fact that we introduced an indirection layer to allow for a stable metadata is only one part of what is needed. We need a well defined domain model that describes what the supported administration capabilities are for a given release. Now I'm thinking that the domain.xml is all that matters. Until a feature of the server has a representation in the domain.xml model, its not properly managable. > > I totally agree. We should focus on the requirements, use-cases and the model/configuration itself. I also agree that something has to be in domain.xml for it to be truly managable. I kind of saw runtime management of components not in domain.xml as more of a stop-gap. However, it probably is easier to just focus on the domain model, and look at the non-classified runtime stuff later, if it is even relevant anymore. Great. I'm a lot more comfortable with this approach. Multiple different management approaches coexisting in the same management API, some of which map back to domain.xml and some not -- yuck. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/536124#536124] Start a new discussion in Management Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

16 years

1
0
0 / 0

Re: [jboss-dev-forums] [Management Development] - domain.xml work

by Jason Greene

Jason Greene [http://community.jboss.org/people/jason.greene%40jboss.com] replied to the discussion "domain.xml work" To view the discussion, visit: http://community.jboss.org/message/536123#536123 -------------------------------------------------------------- > Emanuel Muckenhuber wrote: > > Seems you misunderstood me. I was not talking about having IOC in the domain.xml at all. I said using IOC for configuration is a problem, since ProfileService does not understand injection. Just look at how persistence overrides are applied to the e.g. the service-binding-manager - where we actually override properties with <inject /> with the beans constructed within profileservice - based on the peristence information. Again this has nothing to do with the actual domain.xml, it is more about the mapping and override layer. The service binding manager should be obviated by the domain model, so there should be no need for injection overrides. Put another way, anything managed by domain.xml should not be allowed in some arbitrary beans.xml descriptor. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/536123#536123] Start a new discussion in Management Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

16 years

1
0
0 / 0

[jBPM Development] - JBPM questions

by Simon Bonello

Simon Bonello [http://community.jboss.org/people/sbonello] created the discussion "JBPM questions" To view the discussion, visit: http://community.jboss.org/message/536099#536099 -------------------------------------------------------------- HI to all, I have some question on JBPM that I need answered. 1. Is it possible to install the JBPM engine without JBoss and sql. (as possible I do not want to add to many components into my current solution). ? 2. Can we start from a particular state without loading the state machine from the database ? 3. is it possible to transition from different two process definitions (i.e form one Jpdl definition call another JPdl definition). 4. Regards Simon -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/536099#536099] Start a new discussion in jBPM Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

16 years

1
0
0 / 0

Re: [jboss-dev-forums] [Management Development] - domain.xml work

by Emanuel Muckenhuber

Emanuel Muckenhuber [http://community.jboss.org/people/emuckenhuber] replied to the discussion "domain.xml work" To view the discussion, visit: http://community.jboss.org/message/536055#536055 -------------------------------------------------------------- Seems you misunderstood me. I was not talking about having IOC in the domain.xml at all. I said using IOC for configuration is a problem, since ProfileService does not understand injection. Just look at how persistence overrides are applied to the e.g. the service-binding-manager - where we actually override properties with <inject /> with the beans constructed within profileservice - based on the peristence information. Again this has nothing to do with the actual domain.xml, it is more about the mapping and override layer. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/536055#536055] Start a new discussion in Management Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

16 years

1
0
0 / 0

Re: [jboss-dev-forums] [JBoss Web Services Development] - Recent changes on CXF integration

by Alessio Soldano

Alessio Soldano [http://community.jboss.org/people/alessio.soldano%40jboss.com] replied to the discussion "Recent changes on CXF integration" To view the discussion, visit: http://community.jboss.org/message/536045#536045 -------------------------------------------------------------- > Richard Opalka wrote: > > Good job Alessio. This was real CXF integration improvement we've been missing. Thanks > Richard Opalka wrote: > > The performance bottleneck during deployment time isn't so significant > and it can be always solved with using separate worker thread to read > the CXF configuration file asynchronously when it will became an real issue. > I'd say we should remove CxfServletExt lazy load of the bus because this is broken > by design. I'm not that sure regarding the considerations on performances above, anyway I agree on saying the lazy behaviour is broken at least for some usecases. Keeping it is probably going to be a pain and causing confusion with the users. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/536045#536045] Start a new discussion in JBoss Web Services Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

16 years

1
0
0 / 0

Re: [jboss-dev-forums] [JBoss Web Services Development] - Recent changes on CXF integration

by Alessio Soldano

Alessio Soldano [http://community.jboss.org/people/alessio.soldano%40jboss.com] replied to the discussion "Recent changes on CXF integration" To view the discussion, visit: http://community.jboss.org/message/536041#536041 -------------------------------------------------------------- > Jim Ma wrote: > > There is one use case I can see now to keep the lazy load support : when user specify both the jbossws-cxf.xml and web.xml to create a service , and there is some configuration item for example "wsdlLocation" in jbossws-cxf.xml needs ServletContextResourceResolver : > <jaxws:endpoint class="foo.Bar" wsdlLocation="WEB-INF/hello.wsdl"/> This is actually not a problem, as currently the CXFServletExt: 1) get the bus created during deployment from the endpoint 2) sets the bus as the thread default 3) updates the bus with the information coming from the ServletConfig: this includes adding that resource resolver to the resource manager 4) properly creates and sets the ServletController using the bus -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/536041#536041] Start a new discussion in JBoss Web Services Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

16 years

1
0
0 / 0

Re: [jboss-dev-forums] [JBoss Web Services Development] - Recent changes on CXF integration

by Jim Ma

Jim Ma [http://community.jboss.org/people/jim.ma] replied to the discussion "Recent changes on CXF integration" To view the discussion, visit: http://community.jboss.org/message/536032#536032 -------------------------------------------------------------- I like your change . It elegently enables other transports support without web.xml. There is one use case I can see now to keep the lazy load support : when user specify both the jbossws-cxf.xml and web.xml to create a service , and there is some configuration item for example "wsdlLocation" in jbossws-cxf.xml needs ServletContextResourceResolver : <jaxws:endpoint class="foo.Bar" wsdlLocation="WEB-INF/hello.wsdl"/> -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/536032#536032] Start a new discussion in JBoss Web Services Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

16 years

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 April 2010