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

[Design of JBoss ESB] - Re: Uniquely identifying services and actions

by mark.little＠jboss.com

Unique within what context? Node, ESB Server, globally etc? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4062068#4062068 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4062068

18 years, 9 months

1
0
0 / 0

[Design of JBoss ESB] - Uniquely identifying services and actions

by tcunning

Do we have a good way of uniquely identifying a service or action? In the MBeans, we're identifying a service by listener-name/service-category/service-name. This seems like it'll be unique per ESB node, but it also seems really clunky. Is there an easier way to identify a particular service? We're identifying actions by action-name within a particular service - is this enough to be unique? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4062067#4062067 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4062067

18 years, 9 months

1
0
0 / 0

[Design of JBoss Web Services] - Project structure for jbossws-2.1.0

by thomas.diesler＠jboss.com

Folks, now that jbossws-2.0.0.GA is out it is time to think about a project structure that gives independent lifecycle to the individual integration projects. The SPI, the container integration layers and the stack integration layers all have independent lifecycle. It should for example be possible to deploy jbossws-2.0.0.GA in jbossas-5.0.x, by updating the jboss50 container integration to the new deployer archtecture. The SVN layout I propose is | jbossws | + container-jboss40 | + container-jboss42 | + container-jboss50 | + stack-native | + stack-metro | + stack-cxf | + spi | + testsuite | Each of the above will have trunk, branches, tags. Projects will have binary dependencies only. For example stack-native and container-jboss50 will have a binary dependency on spi. jbossws/trunk will be removed, jbossws/branches and jbossws/tags will be moved to old.releases View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4062063#4062063 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4062063

18 years, 9 months

1
0
0 / 0

[Design of JBoss Portal] - Re: Java 5 migration strategy

by julien＠jboss.com

I don't know yet. It looks like the backport is supposed to be better than the original since they did bug fixes and improved some features. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4062022#4062022 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4062022

18 years, 9 months

1
0
0 / 0

[Design of JBoss Portal] - Re: Portal build

by pgier

I think eventually, we will want to switch to maven, so that there is consistency between the jboss projects/products, builds are easier to understand/maintain, and more features are available. The approach that I've been taking with other projects, is to add the maven build scripts (pom.xml) along side the ant build. This way either one can be used during a transitional period, until people are basically happy with the maven build. I don't think the complaints that I've heard are serious enough to stop the migration to maven. The main complaints about maven that people have seem to be: Lack of flexibility - Maven forces your project to follow certain conventions, which can be difficult for larger projects. These issues can normally be handled by restructuring certain parts of the project, or creating new plugins, or just finding the right plugin/configuration to use. Lack of IDE integration - IDE integration exists for Eclipse and IDEA. It's not perfect, but it's getting better, and with a little research/configuration most things can be done. Bugs/Lack of Docs - Again Maven works pretty well for basic stuff, but with more complex configuration, finding bugs is not uncommon. You can either create a codehaus jira issue, or create an issue under JBBUILD, and I can try to fix it. I haven't really looked at migrating the portal build yet. I'm currently working on aop and the app server and probably won't get to portal for a couple of months. If someone wants to start working on it, you can try creating some basic pom.xml files that just list the dependencies, and compile the code. You can look at the microcontainer build as an example. There are also maven ant tasks (http://maven.apache.org/ant-tasks.html) which allow you to use maven's dependency management and some other features from within an ant build script. This can be useful during the transition, but is probably not a good long term solution. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4062016#4062016 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4062016

18 years, 9 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: What is going on with aliases?

by adrian＠jboss.org

Looking at the code, I think this should also work to alias JMX contexts? but it obviously needs testing. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4062011#4062011 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4062011

18 years, 9 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: What is going on with aliases?

by adrian＠jboss.org

Ok, I see what you are doing. Each alias is associated with a name | <deployment xmlns="urn:jboss:bean-deployer:2.0"> | <alias name="Test">MyAlias</alias> | </deployment> | So you're saying I want to alias the context "Test" with the new name "MyAlias". And this is a seperate deployment to where "Test" is defined. It's an interesting idea. But if this really is the solution then it needs some kind of marker in the component to say it is "NOT REAL", otherwise other stuff built on the deployers like what I'm going to do with the metadata repository and jsr77 or what the profile service is doing is going to get very confused. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4062009#4062009 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4062009

18 years, 9 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: Using JBossSerialization with HttpSession Replication (J

by ricardoarguello

I see... Serializing non-serializable objects was my original idea. I know JBoss Serialization can do that, maybe I'll develop this functionality for JBoss 4.x and 5.0. I have added an issue: http://jira.jboss.org/jira/browse/JBAS-4524 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4062008#4062008 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4062008

18 years, 9 months

1
0
0 / 0

[Design the new POJO MicroContainer] - What is going on with aliases?

by adrian＠jboss.org

| public class AbstractKernelDeployment extends JBossObject | implements KernelDeployment, MutableLifecycleHolder, Serializable | { | - private static final long serialVersionUID = 1; | + private static final long serialVersionUID = 2l; | | /** The name of the deployment */ | protected String name; | @@ -92,7 +92,7 @@ | protected ControllerMode mode; | | /** The aliases */ | - protected Set<NamedAliasMetaData> aliases; | + protected List<NamedAliasMetaData> aliases; | None of this makes any sense to me. I don't remember you discussing any of these changes? The order of the aliases cannot matter and you can't have an alias more than once. So why a List when a Set describes exactly what is required. Also what does it mean for a deployment rather than a bean to have an alias? Is this a Spring thing? As far as I can tell, your DeploymentAliasMetaDataDeployer is just going to fail when a deployment has more than one bean in it. You will try to apply the alias names to all the beans in the deployment. Only one of the beans can have an alias. It must be unique! Also, the component deployer was not intended for this kind of thing. The idea of a component is to represent a part of a deployment, e.g. a single ejb in an ejb jar or single bean in a -beans.xml soon I will be using the components to assign scopes for the MetaDataRepository where instance=component-name This kind of hack is just going to confuse things. There should be only one scope not a scope for every alias. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4062001#4062001 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4062001

18 years, 9 months

1
0
0 / 0

[Design of JBoss Portal] - Re: Portal build

by bdaw

I think that migration process is always time consuming: - for the person who does it - portal is quite a big project right now and we have some hacks in our current build. - for the developers to learn the usage, and how to extend/add stuff I don't think that any of portal core devs will deal with migration as we all agree it's not a high priority task and no one is really skilled in maven :). So the question close to "which build system and why?" is "who will do it?". If we don't have any resource/contributor that can migrate our build to something else whole discussion can be worthless. Then we stay only with - "what should be improved in buildmagic?" View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4061995#4061995 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4061995

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 July 2007