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

[Design of POJO Server] - Re: Integrating aop-mc-int bean metadata with AS5

by kabir.khan＠jboss.com

While I get the correct AspectMaager, scoped aop (with my WIP) is broken in AS, following the latest MC update. I think it is because the aliases are not working as they used to so e.g. my aspect bindings are not installed since the dependencies are not satisfied since it cannot find the dependencies. I have had a look at DescribeAction.applyAnnotations(), and from what I can see the resulting AliasesAnnotationPlugin.internalApplyAnnotation() returns immediately due to no @Aliases found in MDR, so the aliases are never set in the bean metadata. Of course, I could be looking in the wrong place :-) As we discussed a while ago, I am adding the @Aliases to the bean metadata: | private void massageScopedBean(BeanMetaData bean) | { | if (scoped) | { | String name = bean.getName(); | String newName = "ScopedAlias_" + sequence + "_" + name; | | BeanMetaDataBuilder builder = BeanMetaDataBuilder.createBuilder(bean); | | //Set the alias to the original name | builder.addAnnotation(new AliasesImpl(name)); | Should this instead be added to MDR? Or are aliases handled some other way? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4170175#4170175 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4170175

17 years, 7 months

1
0
0 / 0

[Design of POJO Server] - Re: ProfileService equiv to ServiceBindingManager

by bstansberry＠jboss.com

"bstansberry(a)jboss.com" wrote : A question is what to do with the old org.jboss.system.ServiceBinding interface and it's usage in ServiceConfigurator (and OldServiceConfigurator): | | ..... | No comments, so I'm going to get rid of this stuff now. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4170151#4170151 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4170151

17 years, 7 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: VFS Memory Deserialization

by kabir.khan＠jboss.com

The following little test that I wrote to see how this fails works for me | package org.jboss.test.deployers.vfs.memory; | | import java.net.URL; | import java.rmi.MarshalledObject; | import java.util.Collections; | import java.util.List; | | import org.jboss.deployers.vfs.plugins.vfs.VirtualFileSerializator; | import org.jboss.test.BaseTestCase; | import org.jboss.virtual.MemoryFileFactory; | import org.jboss.virtual.VFS; | import org.jboss.virtual.VirtualFile; | | /** | * | * @author <a href="kabir.khan(a)jboss.com">Kabir Khan</a> | * @version $Revision: 1.1 $ | */ | public class MemoryTestCase extends BaseTestCase | { | | public MemoryTestCase(String name) | { | super(name); | } | | public void testSerialize() throws Exception | { | URL url = new URL("vfsmemory://aopdomain/org/acme/test/Test.class"); | MemoryFileFactory.createRoot(new URL("vfsmemory://aopdomain")); | | MemoryFileFactory.putFile(url, new byte[] {'a', 'b', 'c'}); | VirtualFile classFile = VFS.getVirtualFile(new URL("vfsmemory://aopdomain"), "org/acme/test/Test.class"); | | assertNotNull(classFile); | | VirtualFileSerializator saved = VirtualFileSerializator.toVirtualFileSerializators(Collections.singletonList(classFile)).get(0); | MarshalledObject mo = new MarshalledObject(saved); | | VirtualFileSerializator loaded = (VirtualFileSerializator)mo.get(); | VirtualFile loadedFile = loaded.getFile(); | | assertNotNull(loadedFile); | assertEquals(classFile, loadedFile); | } | | protected void setUp() throws Exception | { | VFS.init(); | super.setUp(); | getLog().info("java.protocol.handler.pkgs: " + System.getProperty("java.protocol.handler.pkgs")); | } | | } | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4170131#4170131 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4170131

17 years, 7 months

1
0
0 / 0

[Design of JBoss Portal] - Re: portal clustering problem when using optimistic locking

by bstansberry＠jboss.com

Preferably do both. I don't want to try to predict what's going to show what, so start with as few moving parts as possible (i.e. default configuration) and see what happens. A cache with CacheMode.LOCAL adds a moving part. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4170126#4170126 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4170126

17 years, 7 months

1
0
0 / 0

[Design of JBoss Portal] - Re: portal clustering problem when using optimistic locking

by prabhat.jha＠jboss.com

Brian, yes, I am already running tests with 5 portal servers in non clustered configuration to verify what you pointed out. I also do not think clustering is the main culprit here and I really hope it's not. I am running with default configuration but if I set cache_mode to LOCAL in cluster modificaiton, it should serve the same purpose right? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4170120#4170120 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4170120

17 years, 7 months

1
0
0 / 0

[Design of JBoss Portal] - Re: portal clustering problem when using optimistic locking

by bstansberry＠jboss.com

I also recommend you test your 5 node setup with any clustering capability turned off. And look at your DB connection pools -- is the number of connections the DB is configured to allow sufficient to meet the demands of 5 nodes? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4170119#4170119 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4170119

17 years, 7 months

1
0
0 / 0

[Design of JBoss Transaction Services] - Re: TransactionManager and AS' ServiceBindingManager

by bstansberry＠jboss.com

"jhalliday" wrote : I've been waiting for ServiceBindingManager to stabilize in AS trunk before updating the transaction integration code to play nice with it. Of course there is an element of chicken and egg here - SBM's not done until it works with the transaction manager :-) True enough. Luckily the SBM that's in place now doesn't work anymore, so that resolves our dilemna. I can just check in what I have to replace it and we don't end up any more broken. anonymous wrote : The MC bean lifecycle methods in the TransactionManagerService already override some of the property file configuration, for example logging and IP address binding. In the latter case we fish the address out of the ServerConfig.SERVER_BIND_ADDRESS system property, largely though ignorance of any more elegant solution. Is there an MC style way to get this value from the server meta data? Simplest is to dependency inject it, with the system property as the value. End result is the same as you have now, but it can be changed by the user. <property name="bindAddress">${jboss.bind.address}</property> I think better is to get the value from the SBM; that way the SBM becomes the source for all binding related metadata. See example below. anonymous wrote : For the port binding, I was planning on changing transaction-beans.xml to contain a port, probably something like: | | property name="port" value="some ref to SBM here" | | and then use that value to override the one from the jta properties file. MC would then automatically ensure SBM deployed before the transaction manager. Yep. The syntax would look like this: | <bean name="TransactionManager" class="com.arjuna.ats.jbossatx.jta.TransactionManagerService"> | <annotation>@org.jboss.aop.microcontainer.aspects.jmx.JMX(name="jboss:service=TransactionManager", exposedInterface=com.arjuna.ats.jbossatx.jta.TransactionManagerServiceMBean.class, registerDirectly=true)</annotation> | | <property name="transactionTimeout">300</property> | <property name="objectStoreDir">${jboss.server.data.dir}/tx-object-store</property> | <property name="mbeanServer"><inject bean="JMXKernel" property="mbeanServer"/></property> | | <property name="recoveryBindAddress"> | <value-factory bean="ServiceBindingManager" | method="getInetAddressBinding" | parameter="TransactionManager"/> | </property> | | <property name="recoveryPort"> | <value-factory bean="ServiceBindingManager" | method="getIntBinding" | parameter="TransactionManager"/> | </property> | </bean> | It can get more involved than that if there are a bunch of bindings (see wiki), but that handles a single pair of properties for an address and port. If the address property was of type String rather than InetAddress, the "method" attribute in its value-factory element would have a value of "getStringBinding". The presence of the bean="ServiceBindingManager" in the value-factory elements triggers the proper dependency relationship in the MC. anonymous wrote : As I understand it this is essentially your proposal 1). Since I've not actually started work on it yet I'm happy to change the approach if you feel one of the others is preferable. No, I think proposal 1) is best; just threw out the others to spark discussion in case that wasn't workable. anonymous wrote : As it happens there is already a JBTM JIRA for adding system property substitution support, but a) I'm not sure it will make the cut for the next release and b) I don't think it's as elegant an approach for this particular problem. Cool. I think system property substitution is a nice thing to have in all our config files, but I agree it's not as elegant for this usage. anonymous wrote : | There are two issues here: all the transaction using JVMs have to agree which interface to bind the port on. They can't use different real addresses, since the port is uniq only in the scope of the address. In the absence of any override we use localhost. This works from a technical standpoint but confuses users who don't understand why the server is listening on that address even if they have specified something else with -b. | | Secondly, each process must obviously have a different port number. Right now we start at a given number and walk the range until we find an unoccupied one. The drawback of this is we may wind up on a port that something else which has not yet started also needs. | | If we wish to configure this though SBM too we clearly need some more properties... Multiple properties are not a problem. The examples above use an overloaded method on the SBM that only takes a single parameter to identify the binding. There are other variants that take a second param to identify a particular binding. As for the localhost vs -b issue, that's a configuration choice. The SBM can certainly handle using a different address value for this binding vs. the others, allowing you to keep "localhost" if you want. Here's how it could all be set up: In bindings.xml: | <bean class="org.jboss.bindings.ServiceBinding"> | <constructor> | <parameter>TransactionManager</parameter> | <parameter>RecoveryManager</parameter> | <parameter>${jboss.bind.address}</parameter> | <parameter>4712</parameter> | </constructor> | </bean> | | <bean class="org.jboss.bindings.ServiceBinding"> | <constructor> | <parameter>TransactionManager</parameter> | <parameter>UUIDFactor</parameter> | <parameter>localhost</parameter> | <parameter>1234</parameter> | </constructor> | </bean> | The TransactionManager bean then becomes: | <bean name="TransactionManager" class="com.arjuna.ats.jbossatx.jta.TransactionManagerService"> | <annotation>@org.jboss.aop.microcontainer.aspects.jmx.JMX(name="jboss:service=TransactionManager", exposedInterface=com.arjuna.ats.jbossatx.jta.TransactionManagerServiceMBean.class, registerDirectly=true)</annotation> | | <property name="transactionTimeout">300</property> | <property name="objectStoreDir">${jboss.server.data.dir}/tx-object-store</property> | <property name="mbeanServer"><inject bean="JMXKernel" property="mbeanServer"/></property> | | <property name="recoveryBindAddress"> | <value-factory bean="ServiceBindingManager" | method="getInetAddressBinding"> | <parameter>TransactionManager</parameter> | <parameter>RecoveryManager</parameter> | <value-factory> | </property> | | <property name="recoveryPort"> | <value-factory bean="ServiceBindingManager" | method="getIntBinding" > | <parameter>TransactionManager</parameter> | <parameter>RecoveryManager</parameter> | <value-factory> | </property> | | <property name="uuidBindAddress"> | <value-factory bean="ServiceBindingManager" | method="getInetAddressBinding"> | <parameter>TransactionManager</parameter> | <parameter>UUIDFactor</parameter> | <value-factory> | </property> | | <property name="uuidPort"> | <value-factory bean="ServiceBindingManager" | method="getIntBinding" > | <parameter>TransactionManager</parameter> | <parameter>UUIDFactor</parameter> | <value-factory> | </property> | </bean> | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4170116#4170116 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4170116

17 years, 7 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: VFS Memory Deserialization

by alesj

"kabir.khan(a)jboss.com" wrote : Is the problem you are seeing that it tries to pass in the whole URL? If possible try breaking it up? | This fails when I try to (de)serialize VirtualFile created in InMemoryClassesDeployer, - http://anonsvn.jboss.org/repos/jbossas/projects/jboss-deployers/trunk/dep... which is part of classpath. For (de)serialization I use the before mentioned mechanism: - http://anonsvn.jboss.org/repos/jbossas/projects/jboss-deployers/trunk/dep... Used here: - http://anonsvn.jboss.org/repos/jbossas/projects/jboss-deployers/trunk/dep... On deserialization of that classpath in-memory VirtualFile, I get that exception. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4170114#4170114 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4170114

17 years, 7 months

1
0
0 / 0

[Design of JBoss Portal] - Re: portal clustering problem when using optimistic locking

by prabhat.jha＠jboss.com

"galder.zamarreno(a)jboss.com" wrote : | Effectively, this means that GC has it. Are these machines multi core? What are the startup options you're using? Did you enable GC logging? Prabhat, I thought we went through similar situation when you're testing 1 node scenarios, didn't we? I think I suggested that you use tools like TDA to discover scenarios like this. Yes, we went through that exercise and because of that we are at this stage. Portal was tuned enough to get the desired performance in one node and that is taken as baseline for scalability testing. As you can see there is no scalability problem with 3 nodes and now with 4 nodes. So, I do not know why GC would be a factor in 5-node cluster when it's not in {1,2,3,4} cluster. Just an FYI: all these machines are of same architecture (multicore 64 bit) and are in the same subnet. Please ping me as needed with server setup information. I did see few threads waiting on DB connection which Brian also pointed out. This was intentionally left out because caching whatever data that threads are trying to get would result into a huge memory footpring in some use cases. But what I am going to do is turn on caching for those data and see what that results into. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4170108#4170108 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4170108

17 years, 7 months

1
0
0 / 0

[Design the new POJO MicroContainer] - VFS Memory Deserialization

by kabir.khan＠jboss.com

"Mail from Ales" wrote : | Since you wrote it :-) | | Why this limitation in VFS:MemoryContextFactory | | | public VFSContext createRoot(URL url) | | { | | try | | { | | String rootName = url.getHost(); | | MemoryContext ctx = registry.get(rootName); | | if (ctx == null) | | { | | String urlPath = url.getPath(); | | if (urlPath != null && urlPath.length() > 0) | | throw new IllegalArgumentException("Root can not contain '/' - " + urlPath); | | | This last exception. | | Can we get past/handle this? | | The issue is when I use this: | - http://anonsvn.jboss.org/repos/jbossas/projects/jboss-deployers/trunk/dep... | It breaks, since it cannot be deserialized - due to that exception. | | We can continue on the forum. :-) | The exception was just there to make sure that people don't try to create roots from URLs such as vfsmemory://root/with/path. What should be used is vfsmemory://root. Is the problem you are seeing that it tries to pass in the whole URL? If possible try breaking it up? If not then the exception can probably be removed View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4170105#4170105 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4170105

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