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

[Design the new POJO MicroContainer] - Core spi

by adrian＠jboss.org

There's not much to say about this. This project just contains the shared api like DeploymentException, attachments and the StructureMetaData. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4058807#4058807 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4058807

18 years, 9 months

1
0
0 / 0

[JBoss Portal Documentation] - Re: Quickstart Guide 2.6 update

by cdelashmutt

xhuang has me beat because I don't have write access to the repo. :) I had just gotten started on chapter 4 and I was going top down working on the text and images at the same time. Should we divide up the work in some way or are you already done? ;) I do think we should add some new things like dashboard customization, and enabling workflow for CMS. As well, some of the items in the quickstart are a bit obsolete and should probably be removed (adding the Nav portlet near the bottom of chapter 4, for instance). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4058795#4058795 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4058795

18 years, 9 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: Setting the properties on the JAXBContext

by heiko.braun＠jboss.com

Just to complete the picture: There is a default API to create JAXBContext's now: | JAXBContextFactory.newInstance().createContext() | The default factory implementation is the one that works with BindingCustomizations: | CustomizableJAXBContextFactory.java | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4058788#4058788 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4058788

18 years, 9 months

1
0
0 / 0

[Design of EJB 3.0] - Re: JBossEjbParsingDeployer can't handle EJB3 jboss.xml

by scott.stark＠jboss.org

"wolfc" wrote : Doh, a xml parsing deployer has order 2000. An annotation parsing deployer needs to run after classloader deployer (4000), so I now have the AppClientScanningDeployer at POSTPROCESS_CLASSLOADER_DEPLOYER (5000). | But this means that a chain of EjbAnnotationParsingDeployer -> EjbParsingDeployer -> JBossEjbParsingDeployer won't work. How can this be resolved? | Instead of simple index based ordering, deployers should be ordered based on what the consume in terms of attachment types. If we have a very aggregate attachment where only pieces are overridden by other deployers, we need a phase notion as well. This is just a relative index based ordering for the attachment type. I don't know if the attachment type ordering is part of the refactoring Adrian has done. Its something we talked about. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4058787#4058787 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4058787

18 years, 9 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: Setting the properties on the JAXBContext

by heiko.braun＠jboss.com

OK Tom, both Thomas and I did agree that the API quickshot was a mess. I did a revamp the API, but the concepts we talked about did remain the same. The SPI now contains | Endpoint.addBindingCustomization (BindingCustomization) | BindingCustomization offers Map like access and will become a generic extension point for binding implementations and is not specific to any stack or binding framework. The native stack implements JAXB binding customization: | /** | * Supported JAXB 2.1 customizations. | */ | public class JAXBBindingCustomization extends BindingCustomization { | | // Use an alternative RuntimeAnnotationReader implementation | public final static String ANNOTATION_READER = JAXBRIContext.ANNOTATION_READER; | | // Reassign the default namespace URI to something else at the runtime | public final static String DEFAULT_NAMESPACE_REMAP = JAXBRIContext.DEFAULT_NAMESPACE_REMAP; | | // Enable the c14n marshalling support in the JAXBContext. | public final static String CANONICALIZATION_SUPPORT = JAXBRIContext.CANONICALIZATION_SUPPORT; | | } | It is recognized by the JAXBContextFactory, when set on the SPI Endpoint. This allows you to supply JAXB customizations at deploy time through an ESB specific deployment aspect (in JBossWS terms spi.deployment.Deployer). This particular deployment aspect should recognize ESB deployments and customize the JAXB marshalling for those endpoints only. I think this SPI change will stand the test of time and allows us to model future ESB requirements (i.e. programmatic deployment) as well. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4058783#4058783 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4058783

18 years, 9 months

1
0
0 / 0

[Design the new POJO MicroContainer] - VFS Deployers and projects

by adrian＠jboss.org

It was totallly ridiculous how many of the deployers had been written without the thought that the deployment might not be backed by a VFS file. One of the aims of the new deployers is to provide a "programmatic" api so you can deploy things without having a file system at all. e.g. Create a datasource (psuedo code) | Deployment deployment = ...; | DataSourceMetaData ds = ...; | deployment.addAttachment(ds); | deploy(deployment); | This would break with the way those deployers were written, they were doing things like: | public void deploy(DeploymentUnit unit) | { | // Oops NPE because getRoot() returns null! | URL url = unit.getRoot().getURL(); | } | Now there are seperate subclasses VFSDeployment and VFSDeploymentUnit that include the VFS based api like getRoot(). There is not such api for the plain Deployments. So if your deployer needs access to the VFS api then it should subclass one of the VFS deployers that will automatically ignore deployments that aren't backed by the VFS. These will give you an api callback like: | public void deploy(VFSDeploymentUnit unit) | { | // Your code here | } | | The check for there being a VFS is already done for you! | e.g. AbstractSimpleVFSRealDeployer | | | | | @Override | | public void deploy(DeploymentUnit unit, T deployment) throws DeploymentException | | { | | if (unit instanceof VFSDeploymentUnit == false) | | return; | | | | VFSDeploymentUnit vfsDeploymentUnit = (VFSDeploymentUnit) unit; | | deploy(vfsDeploymentUnit, deployment); | | } | | /** | | * Deploy a deployment | | * | | * @param unit the unit | | * @param deployment the attachment | | * @throws DeploymentException for any error | | */ | | public abstract void deploy(VFSDeploymentUnit unit, T deployment) throws DeploymentException; | | | | NOTE: All the parsing deployers (since they need the VFS to access xml files, etc.) | have this pattern automatically as well. | | So now you no longer have to worry about the NPE described above. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4058757#4058757 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4058757

18 years, 9 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Deployer Project Structure

by adrian＠jboss.org

Since I making incompatible changes to the deployer api which means updating virtual all users of the api, I decided to do some "Dillionism" and restructure the project into 4 areas. This is really more than just "Dillionism" because it makes people think about where and how they implement things. The structure is broken down as follows: * Core - These are datastructures and helpers that are useful in all the projects. * Client - The client side api - this is intended to be used outside jboss * Structure - The core infrastructure for the structural deployers - it also defines the core datastructures used by the deployers * SPI/Impl - This is the deployers and MainDeployer * VFS - VFS extensions to the above, see the later post on why the VFS is seperated Some quick comments: * Most of the projects are seperated into spi/impl, e.g. deployers-client and deployers-client-spi The one exception is the structure project. Since the only implementation of the structure is via the VFS, the implementation of this spi is actually in the deployer-vfs project * The core api defines the StructureMetaData. I don't really like this being here, but it is used by the client side api. As such, we can't really have things from the server side leaking into this code, so I didn't want to put it into the structure project. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4058749#4058749 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4058749

18 years, 9 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: New Deployer changes - overview

by adrian＠jboss.org

AOP issue thread raised here: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4058739#4058739 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4058740#4058740 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4058740

18 years, 9 months

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Deployer Changes for AOP

by adrian＠jboss.org

Related to this thread: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4058730#4058730 The AOPDeployer for JBoss5 needs updating and aop re-releasing. See jboss-head/system/src/main/org/jboss/aop/temp/AOPDeployer.java for an example of what this should look like. Once that is done, the config in server/src/etc/conf/default/bootstrap-beans.xml can be reverted: |  | <bean name="AspectDeployer" class="org.jboss.aop.deployers.temp.AspectDeployer"> | While I was there I made some other changes, but there are still more that need doing (in the error handling strategy). The changes I made are: 1) You now inject the AspectManager. 2) I fixed the undeployment error handling such that it tries to complete all undeployment, previously it had this bad pattern: | for (Object x : deployed) | { | try | { | undeploy(x); | } | catch (Throwable t) | { | // Oops, we stop undeploying on the first error, | // meaning not everything gets undeployed! | throw new RuntimeException(t); | } | } | I've changed it to a WARN. It should also really be undeploying in the reverse order of what gets deployed. Similarly I fixed this stupid code - partly for the same reason, but also partly because there is no possible reason why closing is an error that is interesting. IMHO have close() throw an exception is just stupid anyway. :-) | try | { | stream.close(); | } | catch (IOException e) | { | throw new RuntimeException(e); | } | The other thing that needs doing is similar to the undeploy problem but for deployment. If you are deploying things in a loop then you need to unwind what you've already done, e.g. this code from inside the deployment infrastructure: | int i = 0; | try | { | while (i < theDeployers.size()) | { | Deployer deployer = theDeployers.get(i); | doInstall(deployer, context, doComponents); | ++i; | } | } | catch (Throwable t) | { | context.setState(DeploymentState.ERROR); | context.setProblem(t); | | // UNWIND THINGS ALREADY DONE | for (int j = i-1; j >= 0; --j) | { | Deployer deployer = theDeployers.get(j); | doUninstall(deployer, context, true); | } | throw t; | } | } | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4058739#4058739 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4058739

18 years, 9 months

1
0
0 / 0

[Design the new POJO MicroContainer] - New Deployer changes - overview

by adrian＠jboss.org

This is a quick brain dump of all the deployer changes I just committed. As usual this is an overview thread, to collect on the information in one place. Create separate threads if you want to discuss indivdual topics in more detail. First, the changes are not yet complete. 1) AOP - AOP has a deployer inside its project. That needs updating and AOP re-releasing. But since AOP is required for EJB3 I've temporarily hacked a new version in the "system" project in org.jboss.aop.temp.AOPDeployer 2) WS - Similarly webservices have their own deployers. I've just disabled webservices for now. I'll be working on this next once I've looked at some other minor loose ends. 3) EJB3 - I've updated the EJB3 deployers to use attachment flows (see below) but I'm not sure if they are correct. Its working on some of the basic tests in the ejb3 project tests. I suspect there may need to be some attachment flow dependency on the security deployer (possibly others?), but I'm not sure where it needs to go. 4) Security - I think this needs a lot more work to where I would like to get it. 5) Embedded - I haven't updated this project to the new deployers. The version I currently have of this project doesn't build so that needs to be fixed before I can do this. Most of the changes should be minor, i.e. updating it to use the new "client side" deployment api. I'm going to break down these posts into the follow areas: * New Project Structure - separation of spi/impl and vfs, etc. * VFSDeployer - why this extra abstraction is important * Core - a quick discussion on the core project * Client - the new "client side" deployment api * Structure - the changes to the structure deployments and how the structure is built * MainDeployer - the changes to the main deployer and how it relates to the client side api * DeploymentContext - how that is nearly invisible now and what needs to be done to complete the process * Deployers - the new stages (real dependencies), attachment flow, changes to how components work, making the parsing deployers "more declarative" * TODO - other work that still needs doing like integrating the new classloader View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4058730#4058730 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4058730

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