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

[Design of EJB 3.0] - Re: JndiInject and confused use of generics for polymorphism

by adrian＠jboss.org

"adrian(a)jboss.org" wrote : | Relatedly, I don't understand why you cannot annotate interceptors | with @JndiInject? | I really meant to say jndi-refs in jboss.xml :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4103848#4103848 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4103848

18 years, 4 months

1
0
0 / 0

[Design of EJB 3.0] - JndiInject and confused use of generics for polymorphism

by adrian＠jboss.org

A number of tests were failing because the @JndiInject handler was commented out. There are 43 references in the ejb3 testsuite. This looks like a confused use of the generic parameter to try to do some type of polymorphism, which obviously isn't supported since the type isn't even available at runtime (well unless you use reflection and do it yourself :-). I don't see why these classes should be generic? Shouldn't all these take some jboss extension interface to the spec defined Environment that both the jboss ejb and interceptors metadata implement? Relatedly, I don't understand why you cannot annotate interceptors with @JndiInject? Also, shouldn't all the annotations have equivalent xml, e.g. DependsHandler doesn't look at the xml model at all, there are only annotations??? I've reinstated the handler, but "fixed" the fact that it wants JBossEnterpriseMetaData only with a hack that checks the type in loadXml() | Index: src/main/org/jboss/injection/JndiInjectHandler.java | =================================================================== | --- src/main/org/jboss/injection/JndiInjectHandler.java (revision 66950) | +++ src/main/org/jboss/injection/JndiInjectHandler.java (working copy) | @@ -29,7 +29,10 @@ | import org.jboss.annotation.JndiInject; | import org.jboss.logging.Logger; | import org.jboss.metadata.ejb.jboss.JBossEnterpriseBeanMetaData; | +import org.jboss.metadata.ejb.spec.EnterpriseBeanMetaData; | import org.jboss.metadata.javaee.jboss.JndiRefMetaData; | +import org.jboss.metadata.javaee.jboss.JndiRefsMetaData; | +import org.jboss.metadata.javaee.spec.Environment; | | /** | * Searches bean class for all @Inject and create Injectors | @@ -37,7 +40,7 @@ | * @author <a href="mailto:bill@jboss.org">Bill Burke</a> | * @version $Revision$ | */ | -public class JndiInjectHandler<X extends JBossEnterpriseBeanMetaData> implements InjectionHandler<X> | +public class JndiInjectHandler<X extends Environment> implements InjectionHandler<X> | { | @SuppressWarnings("unused") | private static final Logger log = Logger.getLogger(JndiInjectHandler.class); | @@ -45,8 +48,10 @@ | public void loadXml(X xml, InjectionContainer container) | { | if (xml == null) return; | - if (xml.getJndiRefs() == null) return; | - for (JndiRefMetaData ref : xml.getJndiRefs()) | + if (xml instanceof JBossEnterpriseBeanMetaData == false) return; | + JndiRefsMetaData jndiRefs = ((JBossEnterpriseBeanMetaData) xml).getJndiRefs(); | + if (jndiRefs == null) return; | + for (JndiRefMetaData ref : jndiRefs) | { | if (ref.getMappedName() == null || ref.getMappedName().equals("")) | throw new RuntimeException("mapped-name is required for " + ref.getJndiRefName() + " of container " + container.getIdentifier()); | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4103847#4103847 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4103847

18 years, 4 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: Strange clustering behaviour when running testsuite offl

by adrian＠jboss.org

I've found. It is the fact that is using the IPV6 stack. So I guess either the JDK or JGroups isn't handling 127.0.0.1 as loopback for IPV6? The following patch solves the problem: | [ejort@warjort testsuite]$ svn diff | Index: imports/server-config.xml | =================================================================== | --- imports/server-config.xml (revision 66950) | +++ imports/server-config.xml (working copy) | @@ -87,6 +87,7 @@ | <jvmarg value="-XX:MaxPermSize=512m" /> | <jvmarg value="-Xmx512m" /> | --> | + <sysproperty key="java.net.preferIPv4Stack" value="true" /> | <sysproperty key="java.endorsed.dirs" value="${jboss.dist}/lib/endorsed" /> | <sysproperty key="jgroups.udp.ip_ttl" value="${jbosstest.udp.ip_ttl}" /> | </server> | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4103844#4103844 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4103844

18 years, 4 months

1
0
0 / 0

[Design of JBoss Portal] - Migrating Novell exteNd portlets to JBoss Portal

by llaxman

I want to migrate novell exteNd portlets developed using Novell exteNd Director 5.2.1 to JBoss Portal. How can I do this? I'm using JBoss Portal 2.6.1 GA with AS bundle and Java 1.5 SDK. Also does JBoss portal support pageflows? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4103843#4103843 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4103843

18 years, 4 months

1
0
0 / 0

[Design of JBossCache] - Re: Optimising contents of a prepare call - JBCACHE-611

by mircea.markus

what about compacting only at replication time? Iterating over the list of changes(method calls) it the transaction entry only once, at replication time might reduce the overall time consumtion of processing this by optimizing the processing (e.g. if there are only 3 method calls then don't use this pattern, start processing the removals first and igonore the corresponding puts etc). This way we can calculate the drawback introducec by compacting as it only happens once, in one place. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4103818#4103818 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4103818

18 years, 4 months

1
0
0 / 0

[Design of JBossCache] - Re: Optimising contents of a prepare call - JBCACHE-611

by manik.surtani＠jboss.com

Bringing this back up, since this is scheduled for inclusion in 2.2.0. As a basic design, I think we should look at a consistent "replay" approach for both pessimistic and optimistic locking (rather than shipping the workspace deltas across for optimistic locking), so we can stick with a single TxInterceptor. Shipping the workspace across will require different TxInterceptor behaviour when receiving a prepare. The actual approach could be quite simple - the TransactionEntry currently maintains a List of MethodCalls. This list is populated by TransactionEntry.addModification(MethodCall m). This method could be modified to perform any compacting on the modification list at this time (if compacting is enabled). Also, as a default, I think compacting *should* be enabled since most transactional calls would involve > 1 method invocation, and even if they didn't the compacting algorithm can only start compacting if there are, say, > 3 modifications at the time. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4103806#4103806 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4103806

18 years, 4 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: Strange clustering behaviour when running testsuite offl

by bstansberry＠jboss.com

I'll poke around a bit and see if something pops out. I can't see why you'd get different behavior with "./run.sh -c all" and starting the testsuite; with the change you made last week to Main(), in both cases JGroups binds to 127.0.0.1. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4103801#4103801 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4103801

18 years, 4 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: Strange clustering behaviour when running testsuite offl

by galder.zamarreno＠jboss.com

do you get the same issue when running the main testsuite? or is the issue limited only to start from ejb3 project? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4103777#4103777 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4103777

18 years, 4 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: Strange clustering behaviour when running testsuite offl

by adrian＠jboss.org

"bstansberry(a)jboss.com" wrote : anonymous wrote : What's the difference? :-) | | Perhaps the setting for node0 in ejb3/local.properties? (Or testsuite/local.properties if running the main testsuite.) | | node0 is localhost, see jboss-head/ejb3/local.properties | | | | #IMPORTANT:- Please do not check this file into CVS with your local changes | | #This file is used to pass config info to targets like clustered-tests | | #Please uncomment or add your properties to this file. | | | | # | | # Both node0 and node1 properties are needed to run clustering tests. | | # e.g., clustered-tests. Note that you will need to have two separate ips | | # (even at the same machine). Actually what we needed are just node0 and node1 | | # ips and the rest are optional. | | # | | node0=127.0.0.1 | | #node0=${env.MYTESTIP_1} | | #node0.http.url=http://192.168.1.103:8080 | | #node0.jndi.url=jnp://127.0.0.1:1099 | | | | node1=${env.MYTESTIP_2} | | #node1.http.url=http://192.168.1.113:8080 | | #node1.jndiurl=jnp://192.168.1.113:1099 | | | | #Timeout for jboss to start | | jboss.startup.timeout=120 | | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4103755#4103755 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4103755

18 years, 4 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: Strange clustering behaviour when running testsuite offl

by adrian＠jboss.org

Even with the network connected, it's taking a lot longer to boot the server from the testsuite: | 2007-11-12 16:52:53,200 INFO [org.jboss.bootstrap.microcontainer.ServerImpl] JBoss (Microcontainer) [5.0.0.Beta3 (build: SVNTag=JBoss_5_0_0_Beta3 date=200711121409)] | Started in 5m:29s:740ms | And it has those flush failure messages: | 2007-11-12 16:48:42,394 DEBUG [org.jboss.ha.framework.server.JChannelFactory] Passing unique node id 127.0.0.1:1099 to the channel as additional data | 2007-11-12 16:48:42,753 INFO [STDOUT] | ------------------------------------------------------- | GMS: address is 127.0.0.1:32822 | ------------------------------------------------------- | 2007-11-12 16:49:06,932 WARN [org.jboss.ha.framework.server.JChannelFactory] Flush failed at 127.0.0.1:32822 DefaultPartition-JMS-CTRL | So it looks like it is not going over loopback even though the server is started with "-b 127.0.0.1"? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4103753#4103753 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4103753

18 years, 4 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 2007