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

[Design of POJO Server] - Re: Deployers Reloaded

by adrian＠jboss.org

Forgot one other requirement. SCOPING Each deployment should be automatically assigned a "scope" which should then be used to tie the deployment and JMX/POJO contexts together. e.g. The deployment might a scope: application=some.ear A subdeployment the scope application=some.ear,deployment=sub.war An MBean created for this deployment application=some.ear,deployment=sub.war,instance=jboss.web:servlet=MyServlet The rules to create these scopes will also allow a scoped metadata deployer to be written, e.g. load additional contextual metadata from a jboss-meta.xml and also tie into the scope/naming rules for JSR77. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4036385#4036385 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4036385

19 years, 1 month

1
0
0 / 0

[Design of POJO Server] - Broken deployers

by adrian＠jboss.org

As far as I am concerned, some of the deployers are broken. Mostly because they don't follow the rule that the parsing deployer creates an attachment for the profile service to override. The AspectDeployer also includes some sort of hack where it only parses AOP annotations if the deployment ends with .aop This needs changing to use some more explicit metadata rule. Or an implicit rule where an aop structure deployer tags the deployment for annotation processing if it ends in .aop This processing should be available to all deployments if they have the specific piece of metadata. Once I write the documentation for the deployers this problem should be more obvious to everybody. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4036382#4036382 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4036382

19 years, 1 month

1
0
0 / 0

[Design of POJO Server] - JAXB Deployer refactoring

by weston.price＠jboss.com

As per this topic http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4036378#4036378 The JAXB deployer provided as part of the MC currently needs to be reworked and moved to either a different project or a new project specifically designed for integration. I am putting this here so it doesn't get lost in the shuffle. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4036380#4036380 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4036380

19 years, 1 month

1
0
0 / 0

[Design of POJO Server] - Deployers Reloaded

by adrian＠jboss.org

This is an informational post. If you want to discuss specific topics raised here, please create a seperate thread rather than creating another unreadable monster thread. :-) Its been over three months since I left the deployers framework for you guys to get on with trying out. I think that's sufficient time for you come up with usecases. I'm now going to rework the deployers in the light of what has been discovered and some extra requirements, some are experimental, others not. PROPER ABSTRACTIONS We need to create the proper abstractions over the DeploymentContext. The DeploymentContext (a replacement for the horrible DeploymentInfo) was only ever intended as an internal booking device to tie the four different views of the data together. 1) Client view - the person requesting the deployment 2) Management view - the managed objects 3) Structure view - Scott already made a start on this 4) Deployer view - the DeploymentUnit The DeploymentInfo was horrible because it leaked implementation details into all sorts of code and nobody knowed whether the information was being updated consistently. The purpose of the abstractions is to ensure that the internal model is exposed consistently to the deployers. Exposing DeploymentContext on the DeploymentUnit was only ever a hack to allow you guys to get on with writing the deployers so we can find out what features were missing. DOCUMENTATION I need to document the Deployers so that people know what the model means and how best to use it. The current AspectDeployer is example where even the main idea of how the new deployers is supposed to work or integrate with the profile service or other deployers (it has a number of other issues as well :-). NEW REQUIREMENTS - FROM THE EXISTING DEPLOYERS Top level only deployers - like the classloading deployer, the security deployer(s) also want to deal only with the top level deployment, this should be handled more transparently Components - this prototype needs completing and like the "top level only" deployers there needs to be extra support for deployers that are only or not interested in components. Ordering - most of the deployers are defining their own ordering rather than using the standard (which kind of defeats the point), see later on state machine and attachment streams. Others? NEW REQUIREMENTS - STRUCTURE Russian doll, etc. - Scott has expressed a requirement to have the old implicit deployment rules. This should really be a pluggable policy. Ideally, we should be able to also implement an "all or nothing" deployment rule as well rather than the current rules where parts of an EAR get deployed because there is explicit rule to stop them (or they are out of order because implicit rules in general don't work). NEW REQUIREMENTS - ATTACHMENT STREAMS Currently a deployment will go through all deployers. The deployer is expected to do something like: | public void deploy(DeploymentUnit unit) | { | MyMetaData md = unit.getAttachment(MyMetaData.class); | if (md == null) | return; | | // do stuff | } | Ideally, we should be able to expose this information such that the deployer is never called if there is no such attachment(s). Similarly the output should be definable so the "main deployer" can order the "stream". e.g. | nothing => ParsingDeployer<DeploymentMetaData> => DeploymentMetaData => ComponentDeployer<DeploymentMetaData, ComponentMetaData> => ComponentMetaData => RealDeployer<ComponentMetaData> | NEW REQUIREMENT - DEPLOYMENT DEPENDENCIES Part of the OSGi work requires classloading dependencies (at both package and deployment level). For non-OSGi deployments this will be definable via jboss-classloading.xml, i.e. export, import, dynamic import and uses (See the OSGi spec for what those are). This means that the deployments themselves will have dependencies so I'm going to introduce the Microcontainer dependency mechanism into the MainDeployer to handle this. In some sense, this also removes some of the ordering problems since the currently defined standard ordering will be replaced with ControllerStates. I think the combination of assigning well defined states when deployers get run, coupled with the attachment streams should handle most cases, but I'm still going to keep the deployer ordering for use cases where this might not be enough to resolve the ambiguity (assuming the order matters? :-). TESTS I don't see any of the new features being used by the deployers in JBossAS or JBoss Embedded having corresponding tests in the JBoss Deployers project. How you guys expect this not to regress is beyond me? I'm going to abstract out what I think are the features intended and create tests for them. I'm not going to create tests for what I think is just broken usage. ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4036378#4036378 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4036378

19 years, 1 month

1
0
0 / 0

[Design of JBoss ESB] - Re: JSR-170 message store

by mark.little＠jboss.com

"kurt.stam(a)jboss.com" wrote : I think we need one extra argument, a message store id/message classification. | I think we want to use the message store for all sorts of purposes. One example would be the DLQ I was talking about, so we need to be able to have 'substore' in this store, where I can store messages for this purpose. Is this posiible? Haven't had a chance to look at the API yet, but can we story/retrieve based on: recipient EPR or sender EPR? Would be cool to be able to send Rules to the store that are executed internally by it and used to generate the response (list of messages). Like stored procedures. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4036315#4036315 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4036315

19 years, 1 month

1
0
0 / 0

[Design of the JBoss EJB Container] - Re: Multiple store managers

by jesper.pedersen

Yeah, my opinion also. Are the QA/doc team still maintaining the source files in CVS (now SVN) - or basically: where should submit my documentation patch ? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4036305#4036305 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4036305

19 years, 1 month

1
0
0 / 0

[Design of the JBoss EJB Container] - Re: jdbc2.StoreManager2 and key-generators

by alex.loubyansky＠jboss.com

Great! Thanks! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4036304#4036304 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4036304

19 years, 1 month

1
0
0 / 0

[Design of the JBoss EJB Container] - Re: jdbc2.StoreManager2 and key-generators

by jesper.pedersen

Sure. I'll port the keygen package and create an issue in JIRA - hopefully the work should finished some time next week for inclusion on Branch_4_2 and HEAD. Thanks for your feedback. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4036302#4036302 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4036302

19 years, 1 month

1
0
0 / 0

[Design of the JBoss EJB Container] - Re: JBAS-4304 - Jboss calls ejbStore inside ejbPostCreate on

by alex.loubyansky＠jboss.com

Ok, doing it. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4036298#4036298 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4036298

19 years, 1 month

1
0
0 / 0

[Design of the JBoss EJB Container] - Re: JBAS-4304 - Jboss calls ejbStore inside ejbPostCreate on

by dimitris＠jboss.org

"alex.loubyansky(a)jboss.com" wrote : Unless someone has a better idea, I could do it. That sounds like a rhetoric question :) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4036296#4036296 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4036296

19 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 April 2007