September 2008 - jboss-dev-forums

by ALRubinger

Brain melt. Just realized I hadn't considered overrides (XML overrides Annotations)... So that'll require some more thought. :) S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4176996#4176996 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4176996

17 years, 6 months

1
0
0 / 0

[Design of JBossCache] - Re: memcached client/server

by bela＠jboss.com

Not sure I'd use a cache loader for a memcached implementation in JBossCache. I would do it as follows: - Goal (like in JGroups' impl) is to have Java clients sit in the address space of the server, so no memcached protocol is required - The memcached protocol is implemented (for remote clients, or clients written in different languages) in a JBC-memcached server. Here, we can copy JGroups' implementation, or any server side impl (there aren't many though) - The server implementation consists of a configuration which replaces the ReplicationInterceptor with a different interceptor (maybe a subclass ?). That interceptor forwards calls to certain FQN to different servers, using consisten hashing over the FQN to always map the same FQN to the same JBC-memcached instance - L1 cache: the results could be stored in the JBC instance, so it would act as an L1 cache Hmm, maybe your CacheLoader thought is not such a bad idea ! The CacheLoader acts as L2 cache and uses consistent hashing to fetch items from given hosts, and JBC itself (in conjunction with evciction) acts as L1 cache... Whichever implementation we pick, it should fit into the architecture of Data Partitioning View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4176995#4176995 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4176995

17 years, 6 months

1
0
0 / 0

[Design of EJB 3.0] - Re: JNDI Bindings

by scott.stark＠jboss.org

"ALRubinger" wrote : | I say make these additive (little harm in unintentional extra bindings). The fail-fast would be to throw an error. | Additive meaning create duplicate bindings? The metadata processing should already be treating mappedName annotation as being overriden by the jboss jndi-name. We don't have an xml form for @RemoteBinding.jndiName do we? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4176993#4176993 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4176993

17 years, 6 months

1
0
0 / 0

[Design of EJB 3.0] - Re: JNDI Bindings

by jaikiran

"ALRubinger" wrote : | I say make these additive (little harm in unintentional extra bindings). The fail-fast would be to throw an error. | | >From what i know of some of the annotations for beans and their corresponding XML equivalent, the XML equivalent in the deployment descriptors is treated as an override for annotations. So is this an option too, to be consistent with the behaviour of other annotations and their equivalent XML? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4176990#4176990 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4176990

17 years, 6 months

1
0
0 / 0

[Design of EJB 3.0] - Re: JNDI Bindings

by ALRubinger

The following should be treated equally: * @Stateful/@Stateless/(a)WhateverEJB.mappedName (or XML equivalent) * jndi-name (jboss.xml) * @RemoteBinding.jndiName The question is, what to do in case of conflict? @Stateless(mappedName="MyBean") | class MyEJB{...} ejb-jar.xml: <mappedName>MyBeanInSpecXML</mappedName> jboss.xml: <jndiName>MyBeanInJBossXML</jndiName> I say make these additive (little harm in unintentional extra bindings). The fail-fast would be to throw an error. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4176988#4176988 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4176988

17 years, 6 months

1
0
0 / 0

[Design of EJB 3.0] - Re: JNDI Bindings

by jaikiran

"jaikiran" wrote : Andrew, | | Currently i think we are not considering the mappedName attribute on the @Stateless annotation | | I used Stateless bean just as an example. In general, i am talking about beans having the mappedName attribute. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4176986#4176986 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4176986

17 years, 6 months

1
0
0 / 0

[Design of EJB 3.0] - Re: JNDI Bindings

by jaikiran

Andrew, Currently i think we are not considering the mappedName attribute on the @Stateless annotation (i think i had tried this on Beta4, not sure of CR1). From what i see of the javadocs of @Stateless: anonymous wrote : mappedName: | A product specific name(e.g. global JNDI name) that this session bean should be mapped to. So if a developer specifies a mappedName for the bean, do we have plans to support that too? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4176985#4176985 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4176985

17 years, 6 months

1
0
0 / 0

[Design of JBossCache] - memcached client/server

by genman

JGroups came out with a demo memcached implementation in Java. So I was wondering why this wasn't ported or done in JBoss Cache yet. I'm thinking it'd be fairly trivial to write a cache loader for JBossCache to talk to memcached, using possibly http://code.google.com/p/spymemcached/ ... No need to reinvent this guy. It needs to be hosted in somebody's Maven repository I guess. The server -- couldn't that just be ported from Bela Ban's code? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4176973#4176973 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4176973

17 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Messages are lost on Queue?

by clebert.suconic＠jboss.com

This is actually affecting clustering, so I'm commenting out callListeners on RemotingConnectionImpl. Test org.jboss.messaging.tests.integration.remoting.DestroyConsumerTest will be failing until this could be properly fixed. (Well.. I could remove the test also, but that would only hide the problem ;-) ) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4176943#4176943 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4176943

17 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Messages are lost on Queue?

by clebert.suconic＠jboss.com

The problem is that when you CTRL-C the client only the listeners are not informed about the destroy. (Actually before Tim's commit today, RemotingConnection::destroy was never being called.) So, I could fix this by calling the listeners upon destroy also. A side effect of that is I'm getting now this exception on regular closes, as destroy is being called either way: " Session with name 6dbb02fb-842d-11dd-8672-00007f000001 was already removed" So, if someone (Tim/Jeff) could please take a look on what's the proper way of doing this? I have committed a fix and a testcase, and you could follow the diffs on this JIRA: https://jira.jboss.org/jira/browse/JBMESSAGING-1421 BTW: I feel like the API on FailureListener is a bit confusing. Shouldn't it be called ConnectionListener, and instead of only a failure shouldn't also have a connectionClosed Method. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4176939#4176939 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4176939

17 years, 6 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 September 2008