October 2006 - jboss-dev-forums - Jboss List Archives

[Design of POJO Server] - Re: Update on metadata progress

by scott.stark＠jboss.org

They have not been checked in yet according to the svn commit messages. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978908#3978908 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978908

19 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Where are metadata classes for JavaEE/EJB?

by bill.burke＠jboss.com

Are these metadata classes for ejb-jar.xml and javaee5.xsd in SVN yet? Where? Augmenting the metamodel with annotation information is something that the EJB team can definately do. As well as getting the metamodel to work with the current deployers. The way I envision it is: 1) A parsing deployer for ejb-jar.xml and one for jboss.xml (I guess so we can deploy wls descriptors and such?) 2) A javax annotation processor for ENC/injection annotations that augment any metadata created by ejb deployer or web deployer 3) org.jboss annotation processor for same thing 4) An EJB deployer that takes metamodel, creates EJB Containers, and deploys based on that metamodel. I or EJB team can take on any one of the tasks as long as the metamodel classes/API are complete. That way you can focus on things closer to the kernel rather than any EJB specific things and we can add in our help. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978903#3978903 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978903

19 years, 5 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: JBMICROCONT-105, structural deployer, vfs refactoring

by scott.stark＠jboss.org

A refactoring I have working with the DeclaredStructure deployer is the following: | public interface StructureDeployer | { | /** | * Determine the structure of a deployment | * | * @param file - the candidate root file of the deployment | * @param metaData - the structure metadata to build | * @param deployers - the available structure deployers | * @return true when it is recongnised | */ | boolean determineStructure(VirtualFile file, StructureMetaData metaData, StructuredDeployers deployers); | | int getRelativeOrder(); | | /** The comparator for relative ordering of deployers */ | Comparator<StructureDeployer> COMPARATOR = new StructureComparator(); | ... | } | where the externalized view of the structure deployers is: | public interface StructuredDeployers | { | /** | * | * @param file - root of the deployment in the VFS | * @param metaData - the existing metadata to use/populate with structure metadata | * @return | * @throws DeploymentException | */ | public boolean determineStructure(VirtualFile file, StructureMetaData metaData) throws DeploymentException; | | /** | * Get the ordered set of deployers. | * @return the ordered set of deployers. | */ | public SortedSet<StructureDeployer> getDeployers(); | /** | * Are there any deployers | * @return | */ | public boolean isEmpty(); | } | to transform the StructureMetaData resulting from the structural parse into a DeploymentContext, there is a StructureVisitorFactory notion that is external to the structure parse. This replaces the CandidateStructureVisitorFactory notion that was incorporated into the abstract structural deployer classes, and is another aspect of the MainDeployer. | public interface StructureVisitorFactory | { | /** | * Create the visitor | * | * @param context the deployment context | * @param attributes the visitor attributes uses {@link VisitorAttributes#DEFAULT} when null | * @return the visitor | * @throws Exception for any error | */ | VirtualFileVisitor createVisitor(DeploymentContext context, StructureMetaData metaData, | VisitorAttributes attributes) throws Exception; | } | The StructureMetaData abstraction is: | /** | * A map of vfs paths to deployment context information. | */ | public interface StructureMetaData | { | public void addContext(ContextInfo context); | public ContextInfo getContext(String vfsPath); | public ContextInfo removeContext(String vfsPath); | } | public interface ContextInfo | { | public String getVfsPath(); | public void setVfsPath(String path); | | public String getMetaDataPath(); | public void setMetaDataPath(String metaDataPath); | | public List<ClassPathInfo> getClassPath(); | public void setClassPath(List<ClassPathInfo> classPath); | } | public interface ClassPathInfo | { | /** | * path relative to the context virtual file. | */ | public String getPath(); | public void setPath(String path); | | /** | * Classpath options | */ | public Map getOptions(); | public void setOptions(Map options); | | public Object getOption(Object key); | public void setOption(Object key, Object value); | } | How does this look? I'm creating some tests that replace the usage of the common ArchiveBrowser to validate that this can be replaced with the vfs/StructuredDeployers abstractions. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978901#3978901 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978901

19 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Client failover redeliveries discussion

by clebert.suconic＠jboss.com

"Tim" wrote : | I don't see why anything would be received twice (apart from non persistent | messages since we lose the acks for them but that's fine) | There are some scenarios I'm thinking about, all of them under incomplete transactions. I will create few testcases and will come up with them to the discussion later. As for your summary list. I'm already doing 4, and will be working on 5 and 6 now. 1-3 is dependent on how we are going to discover nodes on ConnectionFactories. (dependent on Remoting) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978900#3978900 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978900

19 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Client failover redeliveries discussion

by timfox

So to summarise: 1) Detect failover 2) Find the "correct" failover server. (This may take several stops) 3) Let the server "stall" you until server failover has completed 4) Recreate the conections, sessions, consumers, producers and browsers. (Swapping ids here sounds fine) 5) Delete any non persistent messages from the client list of unacked messages in any sessions in the failed connection. 6) Send a list of the ids of the peristent messages for each consumer that failed to the server. For each list recreate the ServerConsumerEndpoint delivery list by removing the refs from the channel and creating deliveries and putting in the list. 7) The connection is now ready to be used Note: We must also ensure that no new connections are created on the failover node while old connections are being recreated, otherwise we can have a situation where the new connections grab the messages which have already been delivered to consumers in the failed connecton! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978893#3978893 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978893

19 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Client failover redeliveries discussion

by timfox

"clebert.suconic(a)jboss.com" wrote : | The consumer is going to be recreated the same way the connection on the previous example. (creating a new consumer / replacing the IDs on the old objects). | | On that case, the new server will think it's a new client connecting and it will resend non committed messages from a durable subscription. (So I hope). | | On that case, I'm considering to ignore message previously sent, and on the list of CurrentTransaction.ACKs(). I just want to know if this is everybody's expected behavior. I don't see why anything would be received twice (apart from non persistent messages since we lose the acks for them but that's fine) As long as you make sure you send the list of ids for the unacked peristent messages and recreate the delivery list on the server you should be fine, before any message delivery occurs then you should be fine. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978890#3978890 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978890

19 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Client failover redeliveries discussion

by timfox

"clebert.suconic(a)jboss.com" wrote : Another point also was the relationship between States, Delegates and JMS facades. Besides the state itself I would have to eventually treat/replace more data. Ok fair enough View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978889#3978889 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978889

19 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Client failover redeliveries discussion

by clebert.suconic＠jboss.com

Another point also was the relationship between States, Delegates and JMS facades. Besides the state itself I would have to eventually treat/replace more data. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978885#3978885 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978885

19 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Client failover redeliveries discussion

by clebert.suconic＠jboss.com

"timfox" wrote : "clebert.suconic(a)jboss.com" wrote : The idea is to get a new connection, but keep the actual delegates we are using. | | | | I see what you are doing. You want to re-use the old delegate instance - in which case you need to change the ids. | | Having said that, why do you want to keep the old delegates? Why not just create new ones? Then you won't have to change any ids - I would have thought this would be simpler and it's what I imagined when I thought this through. That's was my first idea, to repalce delegates. But it was easier to just replace the ID instead of replacing eventually listeners and things like that. If I wanted to repalce the entire delegate I would have more data to replace (think about listeners), consequently more space for errors. Replacing the ID was just easier. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978883#3978883 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978883

19 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Client failover redeliveries discussion

by clebert.suconic＠jboss.com

"Tim" wrote : | "Clebert" wrote : | | Second point also: | | | | What to do when a durable subscriber gets the queue refilled? | | - The client will probably receive the message again. I would just ignore redeliveries. | | | | I don't understand the issue here. Can you explain more? | The consumer is going to be recreated the same way the connection on the previous example. (creating a new consumer / replacing the IDs on the old objects). On that case, the new server will think it's a new client connecting and it will resend non committed messages from a durable subscription. (So I hope). On that case, I'm considering to ignore message previously sent, and on the list of CurrentTransaction.ACKs(). I just want to know if this is everybody's expected behavior. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978882#3978882 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978882

19 years, 5 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 October 2006