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

[Deployers on JBoss (Deployers/JBoss)] - Re: jee module's alt-dd

by alex.loubyansky＠jboss.com

Fixed in the AbstractVFSParsingDeployer. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4144779#4144779 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4144779

17 years, 11 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Pulling security out as a separate module

by anil.saldhana＠jboss.com

Currently I have made ejb3 core independent of JBossAS/security code base. There is some redundancy in ejb3/security submodule. But I am in the process of removing that. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4144637#4144637 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4144637

17 years, 11 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: JBAS-4919 - ha singletons in heterogenous topologies

by bstansberry＠jboss.com

Go ahead and return null, update the javadoc to reflect the fact it might return null, and have HASingletonElectionPolicyBase handle the null properly. The javadoc doesn't say it won't return null. And null is the only logical answer if the service isn't deployed anywhere. So adding a lot of workarounds to deal with it doesn't seem worth it. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4144632#4144632 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4144632

17 years, 11 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Pulling security out as a separate module

by anil.saldhana＠jboss.com

http://jira.jboss.com/jira/browse/EJBTHREE-1296 I have started work on this. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4144607#4144607 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4144607

17 years, 11 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: JBAS-4919 - ha singletons in heterogenous topologies

by galder.zamarreno＠jboss.com

A 3rd possibility would be to add a 2rd method to org.jboss.ha.singleton.ExtendedElectionPolicy called something like: pickSingletonIfExists() and call that from HASingletonElectionPolicyBase.isElectedMaster() if exists, otherwise call existing pickSingleton. pickSingletonIfExists() would return null if no cluster nodes were found. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4144590#4144590 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4144590

17 years, 11 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: JBAS-4919 - ha singletons in heterogenous topologies

by galder.zamarreno＠jboss.com

I'm back :) I've got this pretty much nailed down for 4.2.x. Here's a summary of what I've done: - created org.jboss.ha.singleton.ExtendedElectionPolicy (dropped verbose HASingleton from class name) which contains setSingletonName()/getSingletonName() methods that would allow a extended election policy to query DRM. The benefit of this is that it allows original isElectedMaster() to still be called as it is, but the difference is in the impl (whether extended or not), or more specifically, in the pickSingleton() impl. - created paralel ExtendedElectionPolicyBase, ExtendedElectionPolicyMBean, ExtendedElectionPolicySimple and ExtendedElectionPolicySimpleMBean to avoid touching any of the existing election policy classes. - HASingletonSupport overrides setupPartition() to be able to set HAPartition and singleton name before first election vote. - setting singleton name is done this way to be able to cope with both extended and non extended interface: try | { | server.invoke(((MBeanProxyInstance)mElectionPolicyMB).getMBeanProxyObjectName(), "setSingletonName", new Object[] {getServiceHAName()}, new String[] {"java.lang.String"}); | } | catch(ReflectionException re) | { | log.debug("Selected election policy does not support setting singleton name, skipping assignment."); | } Remember than in 4.x, we set the eviction policy via proxy: <depends optional-attribute-name="ElectionPolicy" | proxy-type="attribute">jboss.examples:service=HASingletonMBeanExample-ExtendedElectionPolicySimple_1</depends> That's pretty much it. There's a final question I wanted to post here for discussion: The current javadoc for APIHASingletonElectionPolicy.pickSingleton()/HASingletonElectionPolicy.pickSingleton(HAPartition) does not mention the possibility of pickSingleton() returning null. In fact, isElectedMaster calls something like: pickSingleton().equals() so it's definitely not ready to accept a null value out of it. When the last node in the cluster is stopping, the existing pickSingleton() implementation just choses itself, even though it's undeploying the ha singleton in the very last node. Bottom line: it's stopping the last node but ends up starting the ha singleton when it shouldn't really. The extended implementation I've worked on can detect this and return null out of pickSingleton(), leading to isElectedMaster returning false. In that situation the HASingleton will not be started as singleton if the last node in the cluster is shutting down. The 2nd is IMO the correct behaivour but requires HASingletonElectionPolicyBase.isElectedMaster() to be able to cope with a null value being returned from pickSingleton(). If I do that, iow if I return null from pickSingleton(), I'm effectively breaking the original API javadoc for pickSingleton() though. The fact that the HASingleton is started during the stoppage of the last node in the cluster might not be a big deal, but I suppose on what the HASingleton.startSingleton() does... Might not be very important at the moment, but all this could be relevant at some point depending on the HASingleton implementations out there and the users' expectations in such circumstances. Thoughts? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4144589#4144589 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4144589

17 years, 11 months

1
0
0 / 0

[Design of EJB 3.0] - Re: EJBTHREE-1291, deployment resolver unification

by scott.stark＠jboss.org

As a first step I removed the EjbModuleEjbResolver from the Ejb3Deployment and added the equivalent functionality to the DeploymentScope interface for which jbossas provides the impl. The impl either relies on the endpoint map produced by the MappedReferenceMetaDataResolverDeployer if enabled, or the EjbModuleEjbResolver which has been copied into jbossas under ejb3 with the package org.jboss.ejb3.deployers.tmp if the ReferenceMetaDataResolverDeployer is enabled (its still the default). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4144557#4144557 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4144557

17 years, 11 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: JBoss Clustering roadmap

by bstansberry＠jboss.com

I've largely stopped using the JIRA JBCLUSTER project for the purposes Ben described above; it was just leading to duplicate effort since most things ended up needing to go into the JIRA JBAS project to actually get scheduled for a release. You can still look at JBCLUSTER for some big picture items. For the real details of what's going to happen though, suggest you look at the JBAS and EJBTHREE projects in JIRA and look at the Clustering component. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4144536#4144536 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4144536

17 years, 11 months

1
0
0 / 0

[Deployers on JBoss (Deployers/JBoss)] - Re: jee module's alt-dd

by alex.loubyansky＠jboss.com

I am going to re-open the issue and do the same for ObjectModelFactoryDeployer. This is needed for the connector alt-dd in EARs. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4144531#4144531 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4144531

17 years, 11 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Programmatic policy for jar handling

by alesj

I'll probably need something like VirtualFilehandler::replaceChild(VirtualFileHandler original, VirtualFilehandler replacement)? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4144493#4144493 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4144493

17 years, 11 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 April 2008