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

[Design of JBossCache] - Re: static field replication in PojoCache

by bela＠jboss.com

#1 Why do we need to annotate someStaticVar in the first place ? Since the class is tagged as @PojoCacheable (that's a stupid name, let's change it to @Replicated or @Clustered !!), someStaticVar needs to be replicated as well ! #2 Of course we need to support another static variable ! Ideally we adhere to the Java semantics #3 Sure. Implementation issue correct ? #4 Or lazy, whatever. Implementation issue again #5 Why ? we can have N someStaticVars per *cluster*... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985138#3985138 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985138

19 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Failover on QueueBrowser

by timfox

There is a certain amount of leeway with QueueBrowsers. The JMS spec doesn't mandate that the browser returns a strict enumeration of all the messages in the queue, and I know that other implementations don't support queue browsers on distributed queues at all, so I would go for active local clustered queue on the new node. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985111#3985111 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985111

19 years, 5 months

1
0
0 / 0

[Design of JBossCache] - Re: static field replication in PojoCache

by genman

Why are 4 and 5 even good ideas, let alone "requirements"? As a user, I would want to specify where the static variable is stored and how and if it is replicated. The "registerClass" would essentially link a class to the cache. A class would have to belong to a single cache. To be fair, I'm not really involved with this feature at all. I'm not the customer. But here are what I believe are "requirements": 1. User needs to be able to specify which PojoCache they are replicating their object with. This is becaues it's a common use case to have multiple PojoCache instances per JVM. 2. User needs to be able to control (turn on/off) replication of the static fields. It needs to be off by default. This is because they might want to use this object in a situation where they aren't using JBossCache, e.g. on a simple client without JBoss Cache. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985110#3985110 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985110

19 years, 5 months

1
0
0 / 0

[Design of JBossCache] - Re: static field replication in PojoCache

by ben.wang＠jboss.com

Sorry, I don't get it. What will registerClass do to POJO? To start replication? Attach to the class loader idea is fine but IMO is making the process more complicated than it should be. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985105#3985105 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985105

19 years, 5 months

1
0
0 / 0

[Design of EJB 3.0] - List<T> and @OneToMany relationships in EJB 3.0

by dkoslu＠cleartalk.net

With EJB 3.0 I am trying to persist classes that use Lists (ie, an order preserving collection) using a "JoinTable". Eg, I want a class A to contain a list of instances of class B: class A { List< B> list; } class B { //whatever } If I specify a @OneToMany annotation on "list", then the generated schema is 3 tables: A, B, and A_B where A_B has 2 columns: a (non-unique) foreign key reference to A, and a foreign key reference to B. This is fine for Collections of course but how is the list ordering preserved? I would expect a 3rd column called "position" or "index" to sort on. I tried it with JBoss and the packaged HSQL database using a @OneToMany annotation (with defaults), and my simple tests seemed to work, that is, list order was preserved. But I suspect the only reason that it worked is because JBoss is relying on the database to retrieve the rows in the same order it persists them, which is a bad assumption. I think the SQL standard says you can not rely on any particular ordering in a general select statement. At least I don't see how else it works. Is this the case? I saw a very old post (2004) by Bill Burke that said JBoss's EJB3 doesn't support Lists yet, but I also read in his new EJB 3.0 book that it does. I'm afraid to rely on Lists persisting/retrieving correctly. Perhaps there is a way I can manually specify a sort column in the join table through @JoinTable or some other annotations..? I can also resort to manually adding and maintaining a sortable "index" field to class B, and using @OrderBy, but that is not always practical (nor correct). thanks -dk View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985095#3985095 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985095

19 years, 5 months

1
0
0 / 0

[Design of JBoss ESB] - Re: JMS Provider(s) Design - JBossMQ/JBossMessaging/ActiveMQ

by kurt.stam＠jboss.com

anonymous wrote : Yes, that is a bad idea as even for a given jms pvoider we potentially need alternate configurations. OK in that case we will have to make it configurable. anonymous wrote : Also, what is the relationship between this configuration object and the service that binds the jms connection factories? I assume it can be a jca deployment, mbean, etc. As is typical for ESBs, this release does not support transactions (in the real world most transports will use files, email, ftp etc). For the time being we use plain JMS, no JCA and/or mbeans. However I'm pretty sure we want to be transactional in the (near?) future. So future release will need JCA for sure. But this is more of a Mark question, I'm sure he will comment on this later this weekend. anonymous wrote : There are some instructions on the wiki Thanks Arvinder, that's a good place for it. (I was going off the email string). I will add to this page as I go. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985083#3985083 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985083

19 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Failover on QueueBrowser

by clebert.suconic＠jboss.com

When we are failing over a Queue, the server who is taking over the load of that queue will then start to have two Queues. In case of a Browser... the Browser will also connect to the new server upon a failure. When this happens we could either use the LocalClusterdQueue on the new server or the original channelID used in the old server. So.. I was wondering what would be the correct behavior. I have already committed code on Browser HA recovery considering the fact we will use the LocalQueue. In case we want to use the original failed queue I will have to add the channelID into BrowserState. I have already added the QueueName and MessageSelector string. I will write testcases as soon as we define what's the correct behavior. Any ideas, Clebert Suconic View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985081#3985081 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985081

19 years, 5 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: JSR-181 Annotation Based UDDI Registration

by jgilbert

Kurt, How is the ESB leveraging jUddi? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985080#3985080 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985080

19 years, 5 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: JSR-181 Annotation Based UDDI Registration

by jgilbert

Didn't see Kurt's posting. Sounds great! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985078#3985078 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985078

19 years, 5 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: JSR-181 Annotation Based UDDI Registration

by jgilbert

That worked!!! This little experiment wasn't so little after all. Based on my prototyping this is what I would refactor: juddi-service.sar - remove org.apache.juddi.registry.RegistryServlet. it is there just to init the juddi engine - instead, init and expose the engine in org.jboss.jaxr.juddi.JUDDIService - change org.jboss.jaxr.juddi.JUDDIServlet to access the engine from the mbean - refactor non-httpservlet related code from org.jboss.jaxr.juddi.JUDDIServlet into a pojo called something like UddiSoapProcessor - create a LocalTransport class that extends SaajTransport but calls UddiSoapProcessor instead of invoking a SOAPConnection - add a new mbean that implements the logic in the UDDIExample - add the ddl from the UDDIExample to the standard script jbossws.sar - deploy as an expanded sar - add commented out JaxrSubDeployerInterceptors to jboss-service.xml - the JaxrSubDeployerInterceptors would be configured with the desired transport : Local or Saaj View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985077#3985077 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985077

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 November 2006