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

[Design the new POJO MicroContainer] - Handling contexts in error

by alesj

We should put more info out when users try to manage contexts that are in Error state. Since currently the only way to do a re-try on that context is to do uninstall/re-install. Users might try this | KernelControllerContext context = getControllerContext("Name1", null); | assertEquals(ControllerState.ERROR, context.getState()); | checkThrowable(ClassNotFoundException.class, context.getError()); | | // a hacky fix, but the point is to get the error away :-) | AbstractBeanMetaData bmd = (AbstractBeanMetaData)context.getBeanMetaData(); | bmd.setBean(Object.class.getName()); | | // we suspect the error was resolved, let's try to install | change(context, ControllerState.INSTALLED); | | assertEquals(ControllerState.INSTALLED, context.getState()); | which looks legit, but the thing is that the context would not be even touched - the code only tries to push non-error contexts. We could enable the push from Error or just add some more info that this is not what the user should do. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130730#4130730 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130730

18 years, 1 month

1
0
0 / 0

[Design of JBoss Web Services] - Re: Simplify deploy/undeploy cycles for different stacks

by adrian＠jboss.org

"adrian(a)jboss.org" wrote : | As for the correct way to do it, look at how the MC/deployers are integrated. | NOTE: I'm not saying the MC project is perfect. e.g. the POJO MC (unlike the deployers) defines the spi and implementation in the same project which is obiviously not ideal. And there's a number of (minor) places where policy, wiring and implementation details are mixed together - meaning re-use or changing behaviour is harder than it should be. ;-( View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130729#4130729 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130729

18 years, 1 month

1
0
0 / 0

[Design of JBoss Web Services] - Re: Simplify deploy/undeploy cycles for different stacks

by adrian＠jboss.org

"thomas.diesler(a)jboss.com" wrote : | AFAICS, your comments relates to AS50 only and how the AS decides to provide the WS funtionality. Much of it I understand and would agree. | The same problem exists in all versions. I was using AS5.0 as an example. As for the correct way to do it, look at how the MC/deployers are integrated. The jars are provided with suitable integration hooks - a SPI (system programmer interface) e.g. MainDeployer, classloading, parsing, etc. These are well defined and "stable" interfaces, implementations and helpers (I quote stable because we still haven't done our CR1 release yet :-) The AS project (system and system-jmx) then uses (and extends them in some places - e.g. legacy jmx integration) them. The deployments (the configuration files) are created by the appserver project where it can modify the behaviour to suit its own requirements. In principle your project should not have to change. Instead what changes is the way it is integrated into the different releases of the appserver (using the mechanism defined by that version/release). For your "community updates" this should just be case of replacing the jars if you have paid any attention to the backwards (and forwards) compatibility of your spi. ANOTHER ASIDE: In principle, going forward, the jboss-integration project should define a webservices spi (interfaces and helpers) which you (or anybody else) can implement to provide webservices for any jboss project that integrates using our standard spi (e.g. AS, embedded, esb, etc.) It would then be a case of writing a JBoss4 subdeployer or a JBoss5 deployer on top of that spi. (I doubt it will ever get done for JBoss4 ;-) This would then embody the three different roles (currently you do all three yourself): * Policy - what needs doing (the user - e.g. JBossAS) * Wiring - How to go about doing it (the api/spi - e.g. jboss-integration) * Implementation - Do it (you - JBossWS) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130728#4130728 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130728

18 years, 1 month

1
0
0 / 0

[Design of JBoss Web Services] - Re: Simplify deploy/undeploy cycles for different stacks

by thomas.diesler＠jboss.com

Please show us how a component targeted for AS50 should be released to the repository in the proper way , such that it satisfies the requirements you state above. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130717#4130717 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130717

18 years, 1 month

1
0
0 / 0

[Design of JBoss Web Services] - Re: Simplify deploy/undeploy cycles for different stacks

by thomas.diesler＠jboss.com

We are providing a community project that people can download in a new version every 8 weeks. With that binary it is possible to call ant deploy-jboss421 ant deploy-jboss422 ant deploy-jboss423 ant deploy-jboss500 against an already released AS version. AFAICS, your comments relates to AS50 only and how the AS decides to provide the WS funtionality. Much of it I understand and would agree. However, what we are discussing here is how we can enable the community to replace/update the web service stack that comes with any supported version of an already released AS version. Generally, we welcome constructive feedback in the form of "Instead of xxxx please consider yyyy" View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130712#4130712 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130712

18 years, 1 month

1
0
0 / 0

[Design of JBoss Web Services] - Re: Simplify deploy/undeploy cycles for different stacks

by adrian＠jboss.org

Guys, why are you writing the deployment framework in the JBossWS project? I've said this many times before, concentrate on webservices and let the AS handle deployment/integration If you have an issue with deployment that needs addressing then deal with it in the deployment project, don't reinvent the wheel in an incompatible way yourself. e.g. in JBoss5 which deployments get deployed (and how they are configured/managed) with be a property of the profile service not some internal hackery by you. Choosing and redeploying the WS stack must be doable there (which is potentially a remote management console managing and provisiong a cluster). All that will happen in the long term is that we will have to unpick your hackery. ASIDE: You're still providing your own as integration in the webservices project. The responsibility of the webservices project is to provide the services the AS project should do the integration that's what it is for. If you don't understand what I mean then consider whether it is upto the webservices project to define the configuration and packaging (a sar) for webservices or whether you should provide the functionality and let the appserver define its own configuration. http://repository.jboss.com/jboss/jbossws-native50/2.0.3.GA/lib/ A few obvious examples of why this is broken: 1) The sar includes thirdparty jars that are not chosen by the AS project 2) The "sar" is in deploy mixing deployment and runtime configuration in its beans.xml The deployers should be the in the deployers folder not the runtime, it should not require runtime dependencies to get the deployers in place they should only deal with metadata (for validation purposes inside a management console the runtime will be mocked or the alternatively the runtime maybe "on-demand" dependent on whether there is a relevant deployment). 3) You have your own "deployer" which means we can't use the AS deployers to "interleave" new behaviour (modification of metadata to change/introduce semantics) The aop and messaging projects have similar problems, although I recently decided to ignore aop's delivery of a sar and recreated it with the configuration required INSIDE THE AS's ASPECT PROJECT (which is only really a partial solution). These complaints will probably fall on deaf ears again? :-( View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130705#4130705 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130705

18 years, 1 month

1
0
0 / 0

[Design of JBoss Web Services] - Re: Simplify deploy/undeploy cycles for different stacks

by richard.opalka＠jboss.com

"alessio.soldano(a)jboss.com" wrote : I like the idea of having the information of what have to be removed upon undeploy included in the deployed stuff itself. Having all the stacks deploy the same jbossws.sar file would also help imho; perhaps we could even put the property file inside it. Yes, I think it's a good place where such text or property file could reside :) "alessio.soldano(a)jboss.com" wrote : An issue I see is how to undeploy previous versions that do not have the property file; perhaps we could find out the union of the files that need to be removed for each stacks undeployment right now? mmhh... Yes, that's the issue. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130694#4130694 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130694

18 years, 1 month

1
0
0 / 0

[Design of POJO Server] - Re: Breaking up jboss.microcontainer.lib

by adrian＠jboss.org

We also need to move container, metatype and classload* out of the MC project. It might also be a good idea to split out container's Class/BeanInfo component (used by JBossXB for example) and the MetaData{Repository} (used by AOP) into seperate projects. We could also make a case for seperating the POJO projects from the deployers. Let's do this for the CR1 release. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130685#4130685 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130685

18 years, 1 month

1
0
0 / 0

[Design of JBoss Web Services] - Re: Simplify deploy/undeploy cycles for different stacks

by alessio.soldano＠jboss.com

I like the idea of having the information of what have to be removed upon undeploy included in the deployed stuff itself. Having all the stacks deploy the same jbossws.sar file would also help imho; perhaps we could even put the property file inside it. An issue I see is how to undeploy previous versions that do not have the property file; perhaps we could find out the union of the files that need to be removed for each stacks undeployment right now? mmhh... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130680#4130680 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130680

18 years, 1 month

1
0
0 / 0

[Design of POJO Server] - Re: ServiceMetaData has the most recent dependencies/attribu

by adrian＠jboss.org

"scott.stark(a)jboss.org" wrote : Its a similar discussion, and I'm not sure what the clone of the ClassLoaderMetaData is acomplishing. | It's not really the same thing. EXPLANATION OF WHAT ALES IS TALKING ABOUT In the BeanMetaData we play around with some things, e.g. (using xml to illustrate) | <deployment> | <classloader/> | <bean1/> | <bean2/> | </deployment> | effectively gets turned into | <bean1> | <classloader/> | <bean1> | <bean2> | <classloader/> | </bean2> | </deployment> | There's a similar issue where a nested bean gets replaced with an inject: | <bean> | <property><bean name="A"/></property> | </bean> | becomes | <bean name="A"/> | <bean> | <property><inject bean="A"/></property> | </bean> | These changes end up being irreversable and so we don't really keep what the user requested. They can't undeploy/modify/redeploy because the metadata has changed in ways they probably didn't expect. The ServiceMetaData doesn't really have the same problem (although it might if we expand its features to be more like the POJO stuff). SERVICEMETADATA AS IMPLEMENTATION DETAIL What this thread is about is whether it is ok to modify the service metadata created by other deployers to add dependencies. This metadata is implementation detail and not seen by the user who deals with the ejb or web metadata. The obvious question is whether this use case is really an implementation detail or something the user should manage. If it is something the user should control (e.g. see the default clustering dependencies deployer), then the dependencies need adding to the ejb/web metadata along other explicit dependencies from jboss{-web}.xml If it is just an implementation that may change in the future then it is probably better modifying the "hidden" ServiceMetaData. TRANSITIVE DEPENDENCIES In practice, this just shows that the EJB/WEB containers are not creating their containers correctly and the respective service being used is not exposed for IOC (or aspect dependency) properly. If they were these kind of transitive dependencies; ejb -> security -> security policy ejb -> security aspect -> security policy injection into the aspect would be would be automatic. AFTERWORD I've deliberately refrained from analysing/commenting on the security deployers/integration (until now) since they are fundamental wrong/broken and need a complete rewrite which we don't have time to do before JBoss5. ;-( I may find time to fix some bits when I sort out the ejb deployers, e.g. one obvious one I saw somewhere was checking if it was an ejb/war by looking for META-INF/ejb-jar.xml or WEB-INF/web.xml. * These files aren't even mandatory anymore (annotations or programmatic deployment) * Somebody could in principle turn another type of deployment into a war by adding Web metadata to the attachments, e.g. exposing an ejb as a webservice That's the whole point of the aspectised deployments. There a few other brain deaths in there (which I saw in passing), but like I said above I haven't seriously anaylzed it. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130678#4130678 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130678

18 years, 1 month

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 February 2008