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

[JBoss Microcontainer Development] - Testing Deployers with new Reflect + ClassPool

by alesj

Reporting my findings on the new ClassPoolTestCase: - http://anonsvn.jboss.org/repos/jbossas/projects/jboss-deployers/trunk/dep... All the simple deployment tests pass, it was the more hierarchy complex (if you can call .ear complex) that immediately failed for me. It appeared that the old ClassPool's ClassLoader was used: | junit.framework.AssertionFailedError: expected:<BaseClassLoader@135da43{vfs://top-level.ear/}> but was:<BaseClassLoader@2cbc86{vfs://simple.jar/}> | at org.jboss.test.deployers.vfs.classpool.test.ClassPoolTest.assertClassPool(ClassPoolTest.java:83) | at org.jboss.test.deployers.vfs.classpool.test.ClassPoolTestCase.testBasicEar(ClassPoolTestCase.java:82) Then I tied the RegisterModuleCallback with ClassLoading to properly track Module creation/destruction. | <bean name="RegisterModuleCallback" class="org.jboss.classpool.plugins.as5.RegisterModuleCallback"> | <install method="addModuleRegistry" bean="ClassLoading" whenRequired="Start"> | <parameter><this/></parameter> | </install> | <uninstall method="removeModuleRegistry" bean="ClassLoading" whenRequired="Start"> | <parameter><this/></parameter> | </uninstall> | </bean> | This now looks like something simply snatches CL under the ClassPool: | junit.framework.AssertionFailedError: expected:<BaseClassLoader@bafdff{vfs://top-level.ear/}> but was:<null> | Also, the assertClassPool method doesn't look valid for all classes. e.g. top deployment unit's classloader cannot see war's classes --> AnyServlet.class in testBasicEar View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4260467#4260467 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4260467

16 years, 5 months

1
0
0 / 0

[Management Development] - Re: jboss-admin-rest

by emuckenhuber

"cvasilak" wrote : | P.S I hope developers excuse me for using "org.jboss.admin.rest" package name. If there is any problem using it I can rename it. I'm not sure about this - in general i would say that usage of "org.jboss.*" should be avoided. I'll see if i can find out more about that. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4260458#4260458 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4260458

16 years, 5 months

1
0
0 / 0

[Management Development] - Re: jboss-admin-rest

by emuckenhuber

Hi Christos, this is interesting. We are planning to provide a REST interface for ProfileService in future as well, but haven't started on that. In your TODO list i read that you have problems starting a stopped component. I remember that we had to do some work there as well, but i'm not sure if this fix made it into 5.1.0.GA. It is fixed in the 5_x branch and in the upcoming 5.2.0.Beta1 release though - this might be related. Briefly looking into your application i noticed that you have a implementation for some of our known Components. I think a more generic mapping between ManagedObjects/Components with their ManagedProperties to xml would be good. This would be needed to allow multiple management clients to reuse the same REST api without further interpretation of the exposed information. In general this mapping should be quite easy and you would be able to handle everything ProfileService exposes. Of course depending on your needs you might want to provide some specific implementations for certain ComponentTypes to simplify the usage. If you are interested in that you can look at some similar code i wrote creating a xml representation of the MetaValues: http://anonsvn.jboss.org/repos/jbossas/branches/Branch_5_x/system/src/mai... for the MetaValue JAXB model. and http://anonsvn.jboss.org/repos/jbossas/branches/Branch_5_x/system/src/mai... as well as http://anonsvn.jboss.org/repos/jbossas/branches/Branch_5_x/system/src/mai... for the transformation. This was written for a different purpose so a few more properties about Components would be definitely needed. Still it should give you a starting point in case you want to look at that. Thanks, Emanuel View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4260457#4260457 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4260457

16 years, 5 months

1
0
0 / 0

[JBoss Web Services Development] - Re: jms transport support in jbossws-cxf

by alessio.soldano＠jboss.com

I'd say start producing a minimal testcase showing how to use with JBossWS-CXF what CXF already provide as is, then we think about possible enhancements / improvements in terms of integration. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4260443#4260443 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4260443

16 years, 5 months

1
0
0 / 0

[JBoss Microcontainer Development] - Re: Getting to a ClassInfo's ClassLoader

by alesj

"alesj" wrote : | OK, this looks reasonable, as to delay class creation as long as we can. | Like I said, just make sure - perhaps it's already part of javassist code - that there is security enforcement. | - https://jira.jboss.org/jira/browse/JBREFLECT-61 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4260437#4260437 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4260437

16 years, 5 months

1
0
0 / 0

[JBoss Messaging Development] - Re: JGroups/JBoss Cache backed PersistenceManager?

by apwalker

If you go down that path I would that a look at using Infinispan http://www.jboss.org/infinispan as it is pretty much going to replace JBossCache. That said why not use the shared file journal failover option to achieve this... See http://hornetq.sourceforge.net/docs/hornetq-2.0.0.BETA5/user-manual/en/ht... for details.... View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4260418#4260418 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4260418

16 years, 5 months

1
0
0 / 0

[jBPM Development] - Re: Problem inserting in JBPM_JOB

by Iecisa

Also we don't understand why doing a put method it takes 10 seconds. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4260383#4260383 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4260383

16 years, 5 months

1
0
0 / 0

[JBoss XML Binding Development] - Re: Customizing XB and performance testing

by alex.loubyansky＠jboss.com

Each number in the table above is an average from 10 tries. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4260358#4260358 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4260358

16 years, 5 months

1
0
0 / 0

[JBoss XML Binding Development] - Customizing XB and performance testing

by alex.loubyansky＠jboss.com

So, the previous tests show that generated parsers/handlers show the best time and significant difference. (Although the time and difference should be taken as a landmark value taking into account that Fast JAXB at this point is very limited in its features and doesn't even collect characters into string values correctly, although it's not affecting the current testcase). This could be a way to go. Starting from scratch though is not the best idea taking into account how much code is using XB and its custom features. Besides, XB-specific annotations and API features, XB kind of extends SAX events, i.e. to events like start/end element, characters, etc it adds start/end model group (sequence, choice, all, unordered sequence), start/end wildcard. This is necessary to support binding not only to types and elements but also to groups of elements. This is by the way is missing from JAXB as well at this point. And our projects do use this feature often. The good thing is that this SAX extension, i.e. the event-producing part of XB is separate from its event-handling part. So, the first thing to try going forward, IMO, would be to try to keep the event-producing part (which is based on SchemaBinding API) and try generating handlers for the event-handling part. In fact, in XB you can always write your own custom handler and plug it in. Which is what I did for the next test. | Parser____first run__1_____10_____100_____1000 | FastJAXB__113.7______2.5___19.8___127.8___838.6 | JAXB______112.7______4.2___36.1___172.1___1080.1 | CustomXB__146.4______5.4___43.0___206.4___1201.8 | XB________153.2______6.3___51.1___245.6___1348.7 | first run - first parsing 1, 10, 100, 1000 - number of iterations (parsings) after the first run the time is in milliseconds So, there is some improvement comparing to the default XB but we still don't beat JAXB and significantly slower than Fast JAXB. I am sure event-producing part can be optimized but it's difficult to say how much at this point. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4260355#4260355 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4260355

16 years, 5 months

1
0
0 / 0

[JBoss Microcontainer Development] - Re: Optimizing ControllerState

by alesj

"adrian(a)jboss.org" wrote : There's also a simple optimization you can add to ControllerState.equals() | Currently it will be doing a string comparison even when the comparison is with itself. :-( | | | | public boolean equals(Object object) | | { | | + if (object == this) | | + return true; | | if (object == null || object instanceof ControllerState == false) | | return false; | | ControllerState other = (ControllerState) object; | | return stateString.equals(other.stateString); | | } | | I think I tried this one + doing a check on state string's hash (checking actual string only if hash's matched; same hash != same state), but it didn't visible speed things, hence more drastic change is wip. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4260354#4260354 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4260354

16 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 2009