September 2006 - jboss-dev-forums

[Design of POJO Server] - Deployment Structure

by adrian＠jboss.org

This is a summary to try to end the discussions that are currently going around in circles. The basic idea follows the "do one thing well principle". There are three components: 1) VFS - responsible for presenting the different protocols as a single consistent file system, and abstracting away things like unpacked directories pretending to be jars or unpacking nested jars. 2) StructureDeployers - responsible for determining the structure of deployments, i.e. what is the classpath, metadata location and subdeployments. 3) Deployers reponsible for working with the above models to deploy stuff. In no way should: 1) The VFS be dealing with deployment decisions. 2) The structure deployers be dealing with protocol issues. 3) The real deployers be dealing with protocol or structural issues. I can think of one current exception to this rule where the jboss-service.xml has an <archives/> that adds additional elements to the classpath. In future, there is likely to be some form of aspectized classloader.xml that will take the place of this element and the loader-repository-config which can be processed by the structure deployers such that this can be deprecated and removed as the legacy mixing of concerns that it is. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3974913#3974913 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3974913

18 years, 3 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: 3.2 alpha 1 release status

by alex.guizar＠jboss.com

I'm referring to protected synchronized boolean isWaiting(Thread thread) { | return (thread.getState()==State.WAITING) | || (thread.getState()==State.TIMED_WAITING); | } Thread.getState() and the Thread.State enum are new to java 5. Perhaps you set your JRE system library to jdk 1.5 in eclipse? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3974909#3974909 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3974909

18 years, 3 months

1
0
0 / 0

[Design of JBoss Serialization] - Re: Support for readObject/readResolve replacement?

by scott.stark＠jboss.org

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

18 years, 3 months

1
0
0 / 0

[Design of JBoss Serialization] - Re: Support for readObject/readResolve replacement?

by clebert.suconic＠jboss.com

Yes, we do. I have testcases on readResolve. Hibernate is using it a lot for proxies, and I"m testing Hibernate proxies on serialization's testsuite. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3974899#3974899 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3974899

18 years, 3 months

1
0
0 / 0

[Design of POJO Server] - Re: Why is DeploymentUnit.getDeploymentContext() deprecated?

by adrian＠jboss.org

"bill.burke(a)jboss.com" wrote : Come to think of it Classpath is more of an abstract thing. We need to know structure and deploy based on a structure. Which is exactly what the structure deployers do. They create the classpath from structure. Exists: Is this a jar? Well the classpath is the root Is this a war? Then the classpath is WEB-INF/classes and WEB-INF/lib/*.jar Doesn't exist: Is this a j2se system classloader, then the classpath is the paths from the system property. Or more likely each path element is made into a deployment unit so you could even add an ear to the classpath. ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3974898#3974898 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3974898

18 years, 3 months

1
0
0 / 0

[Design of POJO Server] - Re: Why is DeploymentUnit.getDeploymentContext() deprecated?

by bill.burke＠jboss.com

Come to think of it Classpath is more of an abstract thing. We need to know structure and deploy based on a structure. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3974896#3974896 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3974896

18 years, 3 months

1
0
0 / 0

[Design of POJO Server] - Re: Why is DeploymentUnit.getDeploymentContext() deprecated?

by bill.burke＠jboss.com

Yeah, I don't think doing deployments based on ClassPath is the way to go. For instance, in an embedded jboss environment (Java SE) every component has the same classpath. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3974895#3974895 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3974895

18 years, 3 months

1
0
0 / 0

[Design of JBoss Serialization] - Support for readObject/readResolve replacement?

by scott.stark＠jboss.org

Do we honor the java.io.Serializable readObject/readResolve contract such that one can control what object is returned? A typical example of using this is the old type safe enum pattern that maps a string/int onto a static final instance. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3974894#3974894 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3974894

18 years, 3 months

1
0
0 / 0

[Design of POJO Server] - Re: Updating docs

by adrian＠jboss.org

"scott.stark(a)jboss.org" wrote : | I believe you, but its not clear how the dependecies are going to be added. If I have simple deployers parsing annotations and descriptors to build the metadata instance graphs, there needs to be a resolution phase for references that can introduce the approriate dependency as a by product of resolving the reference to the ejb, queue, datasource, etc. | P.S. I didn't say it would easy. This is one reason why I didn't complete the MetaData stuff since it needs some real world implementation/usage to flush out all the details. The basics seem easy to me? real deployer -> decide scopes (mutable and full) metadata deployer -> populate ad hoc metadata at the defined scope The part that is hard (especially when you get the kind of ad hoc, ill thought out rules in the javaee specs) is: user deployer -> process the metadata from this full scope into some bean deployment that can take part in the dependency mechanism The staged deployers help since all the real deployers (defining the scopes) and metadata deployers (populating the metadata) are done before the user deployers are run. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3974892#3974892 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3974892

18 years, 3 months

1
0
0 / 0

[Design of POJO Server] - Re: VFS isLeaf() vs isDirectory()/isFile()

by adrian＠jboss.org

"scott.stark(a)jboss.org" wrote : | I think we need a basic vfs notion, and an attributed vfs notion where the attributed vfs is a result of metadata coming from the structural analysis. In the attributed vfs I can ask is a non-leaf a deployment container or not. | The attribute VFS notion is the DeploymentContext. The "isDeployment" is determined by the structure deployers (or you can pass it in as a predetermined deployment context). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3974886#3974886 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3974886

18 years, 3 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums September 2006