February 2010 - jboss-dev-forums - Jboss List Archives

[JBoss Microcontainer Development] New message: "Re: AnnotatedElementMetaDataLoader component metadata optimization"

by Kabir Khan

JBoss development, A new message was posted in the thread "AnnotatedElementMetaDataLoader component metadata optimization": http://community.jboss.org/message/526801#526801 Author : Kabir Khan Profile : http://community.jboss.org/people/kabir.khan@jboss.com Message: -------------------------------------------------------------- I changed it to use UnmodifiableScopeKey for both CLASS and JOINPOINT levels. When creating UnmodifiableScopeKey, there was still some overhead in unnecessarily creating the parent ScopeKey.scopes map which will always be ignored, so I have made that lazily initialized in ScopeKey.addScope(Scope). -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/526801#526801

14 years, 3 months

1
0
0 / 0

[JBoss Microcontainer Development] New message: "Re: AnnotatedElementMetaDataLoader component metadata optimization"

by Kabir Khan

JBoss development, A new message was posted in the thread "AnnotatedElementMetaDataLoader component metadata optimization": http://community.jboss.org/message/526747#526747 Author : Kabir Khan Profile : http://community.jboss.org/people/kabir.khan@jboss.com Message: -------------------------------------------------------------- Ok, I'll go with the singleton. The problems I was seeing with returning the singleton was that its getValidTime() method returned null, adding a validTime field makes all tests in mdr and kernel pass. I'll add a simple test for that and commit what I have so far against https://jira.jboss.org/jira/browse/JBMDR-66 So far we avoid creating AnnotatedElementLoaders and ScopeKeys for the cases where a member does not have any annotations. I think this could be taken a bit further, when a member has annotations, we currently create an AnnotatedElementLoader and thus a ScopeKey. As mentioned ScopeKeys are expensive to create due to creating their contained ConcurrentSkipListMap and this add call in the constructor which adds to the ConcurrentSkipListMap: public ScopeKey(Scope scope) { addScope(scope); } Since it looks like there will only be one scope level in the key created by AnnotatedElementLoader, I am going to play with changing private static final ScopeKey getScopeKey(AnnotatedElement annotated) { Scope scope; if (annotated instanceof Class) { Class<?> clazz = Class.class.cast(annotated); scope = new Scope(CommonLevels.CLASS, clazz); } else if (annotated instanceof Member) { Member member = (Member) annotated; scope = new Scope(CommonLevels.JOINPOINT, member); } else { return ScopeKey.DEFAULT_SCOPE; } return new ScopeKey(scope); } to private static final ScopeKey getScopeKey(AnnotatedElement annotated) { Scope scope; if (annotated instanceof Class) { Class<?> clazz = Class.class.cast(annotated); scope = new Scope(CommonLevels.CLASS, clazz); return new ScopeKey(scope); } else if (annotated instanceof Member) { Member member = (Member) annotated; scope = new Scope(CommonLevels.JOINPOINT, member); return new SingleLevelScopeKey(scope); } else { return ScopeKey.DEFAULT_SCOPE; } } where SingelLevelScopeKey will be a lightweight implementation of ScopeKey that does not have the internal ConcurrentSkipListMap. I might even be able to use the existing UnmodifiableScopeKey, so I will look into that first. I think this could this also be used for the CLASS scope? I need to check, but need to see if this could this also be used for the other metadata retrievals. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/526747#526747

14 years, 3 months

1
0
0 / 0

[JBoss Microcontainer Development] New message: "Re: AnnotatedElementMetaDataLoader component metadata optimization"

by Ales Justin

JBoss development, A new message was posted in the thread "AnnotatedElementMetaDataLoader component metadata optimization": http://community.jboss.org/message/526742#526742 Author : Ales Justin Profile : http://community.jboss.org/people/alesj Message: -------------------------------------------------------------- > Returning NullAnnotatedElementMetaDataLoader.INSTANCE gives loads of errors in the jboss-kernel project, but they might be due to my NullAEMDL making some wrong assumptions, so I'll have a look at that. I would go with NAEMDL. You need to check for emtpy annotations anyway, so there is no overhead if instead of null you return NAEMDL. Btw: NAEMLD doesn't need to have its variables static -- it will be singleton. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/526742#526742

14 years, 3 months

1
0
0 / 0

[JBoss Microcontainer Development] New message: "Re: AnnotatedElementMetaDataLoader component metadata optimization"

by Kabir Khan

JBoss development, A new message was posted in the thread "AnnotatedElementMetaDataLoader component metadata optimization": http://community.jboss.org/message/526739#526739 Author : Kabir Khan Profile : http://community.jboss.org/people/kabir.khan@jboss.com Message: -------------------------------------------------------------- Both of these fixes give problems when running the kernel tests. Returning null gives a few errors similar to the ones in MDR's tests, i.e. always expecting component metadata to be non-null in AnnotatedMethodTestCase and AnnotatedConstructorTestCase. This one line fix in AnnotatedMethodTestCase (and similar in AnnotatedConstructorTestCase) solves the problem and all the tests in kernel modules pass. private Annotation[] getComponentMetaData(KernelControllerContext context, Signature signature) { KernelMetaDataRepository repository = context.getKernel().getMetaDataRepository(); MetaData metaData = repository.getMetaData(context); MetaData component = metaData.getComponentMetaData(signature); if (component == null) return new Annotation[0]; return component.getAnnotations(); } Returning NullAnnotatedElementMetaDataLoader.INSTANCE gives loads of errors in the jboss-kernel project, but they might be due to my NullAEMDL making some wrong assumptions, so I'll have a look at that. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/526739#526739

14 years, 3 months

1
0
0 / 0

[jBPM Development] New message: "presumable bug JPDL 4 Graphical Editor, erase <field>"

by ciccio ciccio

JBoss development, A new message was posted in the thread "presumable bug JPDL 4 Graphical Editor, erase <field>": http://community.jboss.org/message/526734#526734 Author : ciccio ciccio Profile : http://community.jboss.org/people/ciccioVega Message: -------------------------------------------------------------- Hi guys. Is this a bug? I'm using JPDL 4 Graphical editor eclipse plugin. I have this process. <?xml version="1.0" encoding="UTF-8"?> <process name="Action" xmlns="http://jbpm.org/4.3/jpdl"> <start g="93,16,48,52" name="start1"> <transition g="-57,-14" name="to Action" to="Action"/> </start> <custom class="it.vega.jbpm.demo.Action" g="66,98,92,52" name="Action"> <field name="action"> <object expr="#{cra}"> <property name="keyword"><string value="NAME"/></property> </object> </field> <transition g="-36,-18" name="to end" to="end"/> </custom> <state g="192,93,92,52" name="state1"/> <end g="75,228,92,52" name="end"/> </process> and the image is 1st attachement. When i insert a transition from <custom> to <state> in diagram mode (2.jpg)..and moving from diagram to source, i see <field> of my custom class erased and i see it how it is shown in 3.jpg. Any suggestions? Am i wrong something? Thanks in advance Ciccio -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/526734#526734

14 years, 3 months

1
0
0 / 0

[JBoss Web Services Development] New message: "Re: Providing JAX-RPC functionalities with CXF and Metro stacks"

by Richard Opalka

JBoss development, A new message was posted in the thread "Providing JAX-RPC functionalities with CXF and Metro stacks": http://community.jboss.org/message/526729#526729 Author : Richard Opalka Profile : http://community.jboss.org/people/richard.opalka@jboss.com Message: -------------------------------------------------------------- I have no complains about merging this JAX-RPC prototype upstream because I can't see different viable solution. I suggest you to merge before VFS3 is in AS trunk, then it will be harder to debug the problems (if any). On the other hand JBossWS 3.3.0.CR1 is coming (code freeze this Friday?) Onward to merge! -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/526729#526729

14 years, 3 months

1
0
0 / 0

[JBoss Web Services Development] New message: "Re: Providing JAX-RPC functionalities with CXF and Metro stacks"

by Alessio Soldano

JBoss development, A new message was posted in the thread "Providing JAX-RPC functionalities with CXF and Metro stacks": http://community.jboss.org/message/526725#526725 Author : Alessio Soldano Profile : http://community.jboss.org/people/alessio.soldano@jboss.com Message: -------------------------------------------------------------- BTW, I really like the idea of coexisting WebServices stacks in AS This is the way to go in the furure IMHO. The particular WebService stack that will be used can be command line configured (see discussion on configurable AS) Well, I think we're not there yet, but this might even be a first step in that direction if that will be the future direction. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/526725#526725

14 years, 3 months

1
0
0 / 0

[JBoss Web Services Development] New message: "Re: Providing JAX-RPC functionalities with CXF and Metro stacks"

by Alessio Soldano

JBoss development, A new message was posted in the thread "Providing JAX-RPC functionalities with CXF and Metro stacks": http://community.jboss.org/message/526723#526723 Author : Alessio Soldano Profile : http://community.jboss.org/people/alessio.soldano@jboss.com Message: -------------------------------------------------------------- Note1) instead of jbossws.deployer we should have two deployers: - jaxrpc.deployer - jaxws.deployer Perhaps that was not clear enough, that's what I have in the prototype impl. jbossws.deployer ----------------------- Contains one stack (Native, CXF, Metro) used for JAXWS functionalities and also for jaxrpc ones in case of Native stack. It has the stack-agnostic-jboss-beans.xml and stack-specific-jboss-beans.xml as usual. jbossws-jaxrpc.deployer -------------------------------- Contains just the two descriptors only jars (jbossws-native-factories.jar, jbossws-native-services.jar), the jboss-classloading.xml, another stack-agnostic-jboss-beans.xml with the new describe stage deployers declaration only. Another stack-specific-jboss-beans.xml (with the jaxrpc only DA) is dropped here by the jbossws-cxf and jbossws-metro install scritps (that basically enable this deployer, which otherwise does nothing). Note2) This is the first initial prototype that will require further cleanup in the future. Sure, I'm probably doing some initial clean up today. Then, if there's no special complaint, I'll merge to trunk. That's because we need to have this go through the usual hudson runs / QA in general, to make sure it always works. Note3) If we're passing all TCK5 suites with Native with this JAX-RPC prototype the I don't see any reason why we couldn't merge this prototype upstream. I did not re-run the TCK5 with Native, but I think there're no problems here, at most we need to verify the jbossws classpath in the porting layer configuration, the new deployers do not enter the game when Native stack is installed. Also, this is something that will probably affect TCK6 only, as we're not going to make this available to AS 5.x. Question) It's not clear to me why this JAX-RPC prototype cannot be backported to AS 501, AS 510 and AS 600M2 AS IL? Are we using some AS upstream features there? This is important to have IMHO to verify Note3) First of all it's a dependency problem. We need to have those jbossws-native-factories.jar and jbossws-native-services.jar installed in jbossws-jaxrpc.deployer. Currently the AS trunk build would put them there. To do that in the AS IL we probably need to have that depend on Native stack. Moreover, we need to have the jbossws-native-core.jar installed in client and common/lib also when the CXF/Metro stacks are deployed. It's not clean to do that during install of a stack, and again if that lib is not there (immagine you have Metro 3.2.2 installed on AS5 and you want to install CXF 3.3.0), we need to depend on Native. Anyway, in the long term, something similar would probably be required nevertheless. Imagine we decide to provide an AS that ships with CXF stack by default, we'll have dependency on native stack too in the component-matrix/pom.xml, which is basically the same idea. But I think going on with this on AS 6 only is pretty much acceptable ATM (AS6 is a major release, blah, blah) and reduces the complexity. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/526723#526723

14 years, 3 months

1
0
0 / 0

[JBoss Tools Development] New message: "Re: JSP Validator gives errors if scriptlets are used"

by Alexey Kazakov

JBoss development, A new message was posted in the thread "JSP Validator gives errors if scriptlets are used": http://community.jboss.org/message/526721#526721 Author : Alexey Kazakov Email : akazakov(a)exadel.com Profile : http://community.jboss.org/people/akazakov Message: -------------------------------------------------------------- This error marker is genareted by JavaScript Syntax Validator (Eclipse WTP). You can try to disable it via Project->Properties->Validation->JavaScript Syntax Validator. JBoss Tools doesn't add such markers and doesn't validate JavaScript at all. If this desn't help then please report this issue to https://bugs.eclipse.org/bugs/ -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/526721#526721

14 years, 3 months

1
0
0 / 0

[JBoss Web Services Development] New message: "Re: Providing JAX-RPC functionalities with CXF and Metro stacks"

by Richard Opalka

JBoss development, A new message was posted in the thread "Providing JAX-RPC functionalities with CXF and Metro stacks": http://community.jboss.org/message/526708#526708 Author : Richard Opalka Profile : http://community.jboss.org/people/richard.opalka@jboss.com Message: -------------------------------------------------------------- BTW, I really like the idea of coexisting WebServices stacks in AS This is the way to go in the furure IMHO. The particular WebService stack that will be used can be command line configured (see discussion on configurable AS) -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/526708#526708

14 years, 3 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums February 2010