December 2006 - jboss-dev-forums - Jboss List Archives

[Design the new POJO MicroContainer] - Re: Other IoC containers support

by alesj

I've added some more tests - mixing MC beans with Spring beans. Injecting Spring beans into MC's works, but the other way around I get this exception: | org.jboss.xb.binding.JBossXBException: Failed to parse source: jar:file:/C:/ales/projects/microcontainer/spring-int/output/lib/jboss-spring-int-test.jar!/org/jboss/test/spring/test/InstantiateMixed2TestCase.xml@13,9 | at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:173) | at org.jboss.xb.binding.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:133) | at org.jboss.kernel.plugins.deployment.xml.BasicXMLDeployer.deploy(BasicXMLDeployer.java:135) | at org.jboss.test.kernel.junit.MicrocontainerTestDelegate.deploy(MicrocontainerTestDelegate.java:196) | at org.jboss.test.kernel.junit.MicrocontainerTestDelegate.deploy(MicrocontainerTestDelegate.java:267) | at org.jboss.test.kernel.junit.MicrocontainerTestDelegate.setUp(MicrocontainerTestDelegate.java:77) | at org.jboss.test.spring.test.TempSpringMicrocontainerTestDelegate.setUp(TempSpringMicrocontainerTestDelegate.java:47) | at org.jboss.test.AbstractTestSetup.setUp(AbstractTestSetup.java:63) | at junit.extensions.TestSetup$1.protect(TestSetup.java:18) | at junit.extensions.TestSetup.run(TestSetup.java:23) | Caused by: java.lang.ClassCastException: org.jboss.xb.binding.sunday.unmarshalling.WildcardBinding | at org.jboss.xb.binding.sunday.unmarshalling.DefaultElementHandler.setParent(DefaultElementHandler.java:109) | at org.jboss.xb.binding.sunday.unmarshalling.SundayContentHandler.endRepeatableParticle(SundayContentHandler.java:730) | at org.jboss.xb.binding.sunday.unmarshalling.SundayContentHandler.endElement(SundayContentHandler.java:138) | at org.jboss.xb.binding.parser.sax.SaxJBossXBParser$DelegatingContentHandler.endElement(SaxJBossXBParser.java:353) | at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source) | at org.apache.xerces.xinclude.XIncludeHandler.endElement(Unknown Source) | at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknown Source) | at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) | at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) | at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) | at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) | at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) | at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) | at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source) | at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:169) | ... 13 more | | This is the XML that is the cause of this | <beans xmlns="urn:jboss:spring-beans:2.0"> | | <bean id="testBean" class="org.jboss.test.spring.support.SimpleBean"> | <property name="refBean"><ref bean="oldBean"/></property> | </bean> | | <bean xmlns="urn:jboss:bean-deployer:2.0" name="oldBean" class="org.jboss.test.spring.support.OldBean"> | <property name="javaBeanString">JavaBean</property> | </bean> | | </beans> View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3994697#3994697 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3994697

19 years, 3 months

1
0
0 / 0

[Design of JBoss Profiler] - can't use profiler

by atamur

I'm using activeTimeout(), run it for 2 seconds. My java params are: -Djava.library.path=/usr/lib -XrunjbossInspector:/tmp,memory=false I'm using profiler CR4, JBoss 4.0.5, java 1.5 At the end, after it stopped, I tryed to use web tool to analyze the biggest log file, but apparently it couldn't understood it's format Here is log when i was running profiler and the error after it JBossProfiler: Initializing DataGathering | ContendedEnter ThreadId -1433647168 -1775966131 | ContendedEnterED ThreadId -1433647168 -1775966130 | ContendedEnter ThreadId -1433648176 -1775966127 | ContendedEnterED ThreadId -1433648176 -1775966126 | ContendedEnter ThreadId -1433647280 -1775966118 | ContendedEnterED ThreadId -1433647280 -1775966115 | ContendedEnter ThreadId -1433647728 -1775966115 | ContendedEnterED ThreadId -1433647728 -1775966114 | JBossProfiler:GCSTART | JBossProfiler:GCFINISH | ContendedEnter ThreadId -1423042952 -1775954230 | ContendedEnter ThreadId -1433647616 -1775953935 | ContendedEnterED ThreadId -1433647616 -1775953934 | ContendedEnterED ThreadId -1423042952 -1775953217 | ContendedEnter ThreadId -1433647168 -1775951999 | ContendedEnterED ThreadId -1433647168 -1775951998 | ContendedEnter ThreadId -1433647280 -1775951918 | ContendedEnterED ThreadId -1433647280 -1775951917 | ContendedEnter ThreadId -1433647840 -1775950986 | ContendedEnterED ThreadId -1433647840 -1775950985 | 18:19:14,120 INFO [PlacesService] SearchRequest: SearchRequest{criteria=SimpleSearchCriteria{isMale=true, ageFrom=0, ageTo=200, goal=1, familyStatus=[21052952], region=ru.mos2.logic.search.SearchRegionRectangle@3b6297, placeTypeId=0, isWithPhoto=false, isOnline=false, goalForDb=1, ageFromShifted=Mon Dec 18 18:19:13 MSK 2006, ageToShifted=Thu Dec 18 18:19:14 MSK 1806}, count=10, start=0} | ContendedEnter ThreadId -1433647392 -1775948924 | ContendedEnterED ThreadId -1433647392 -1775948922 | ContendedEnter ThreadId -1433648064 -1775948921 | ContendedEnterED ThreadId -1433648064 -1775948920 | JBossProfiler:GCSTART | JBossProfiler:GCFINISH | ContendedEnter ThreadId -1433647952 -1775933715 | ContendedEnterED ThreadId -1433647952 -1775933714 | ContendedEnter ThreadId -1433647728 -1775933712 | ContendedEnterED ThreadId -1433647728 -1775933710 | ContendedEnter ThreadId -1433647616 -1775933707 | ContendedEnterED ThreadId -1433647616 -1775933705 | ContendedEnter ThreadId -1433648064 -1775910168 | ContendedEnterED ThreadId -1433648064 -1775910166 | ContendedEnter ThreadId -1433647280 -1775910165 | ContendedEnterED ThreadId -1433647280 -1775910163 | ContendedEnter ThreadId -1433647168 -1775910161 | ContendedEnterED ThreadId -1433647168 -1775910160 | JBossProfiler:GCSTART | JBossProfiler:GCFINISH | ContendedEnter ThreadId -1452714880 -1775909293 | ContendedEnterED ThreadId -1452714880 -1775909293 | ContendedEnter ThreadId -1433647280 -1775906117 | ContendedEnterED ThreadId -1433647280 -1775906115 | ContendedEnter ThreadId -1433647616 -1775906114 | ContendedEnterED ThreadId -1433647616 -1775906113 | ContendedEnter ThreadId -1433647952 -1775906111 | ContendedEnterED ThreadId -1433647952 -1775906111 | ContendedEnter ThreadId -1433648064 -1775906110 | ContendedEnterED ThreadId -1433648064 -1775906109 | ContendedEnter ThreadId -1433647952 -1775905099 | ContendedEnterED ThreadId -1433647952 -1775905099 | ContendedEnter ThreadId -1433648064 -1775905096 | ContendedEnterED ThreadId -1433648064 -1775905095 | ContendedEnter ThreadId -1433647392 -1775905075 | ContendedEnterED ThreadId -1433647392 -1775905073 | ContendedEnter ThreadId -1433647952 -1775904082 | ContendedEnterED ThreadId -1433647952 -1775904026 | JBossProfiler:GCSTART | JBossProfiler:GCFINISH | ContendedEnter ThreadId -1433647392 -1775880887 | ContendedEnterED ThreadId -1433647392 -1775880885 | ContendedEnter ThreadId -1433648064 -1775861664 | ContendedEnterED ThreadId -1433648064 -1775861661 | ContendedEnter ThreadId -1433647616 -1775861661 | ContendedEnterED ThreadId -1433647616 -1775861611 | Stopping DataGathering | 18:23:20,738 INFO [STDOUT] usando /tmp | 18:23:20,866 WARN [[upload]] Servlet.service() for servlet upload threw exception | java.io.StreamCorruptedException: invalid stream header | at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:764) | at java.io.ObjectInputStream.<init>(ObjectInputStream.java:277) | at org.jboss.profiler.web.servlets.ServletUpload.doPost(ServletUpload.java:57) | at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) | at javax.servlet.http.HttpServlet.service(HttpServlet.java:810) | at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) | at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) | at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3994695#3994695 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3994695

19 years, 3 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - QueueBrowser semantics

by timfox

Currently we have implemented the queue browser to iterate over the set of all undelivered + delivered but not yet acknowledged messages in a queue. I don't see anything particularly wrong with this, but neither can I see anything in the JMS spec that says the iteration has to include the set of delivered but not yet unacknowledged methods. The reason I bring this up is that I would like to remove the set of deliveries which are currently managed in ChannelSupport. For primary JMS use cases: delivery, acknowledgement, cancellation it is not necessary for the channel to maintain a delivery set. Removing it would greatly simplify the code and probably improve performance and reduce scope for race conditions. If we can relax the queue browsing implementation to not include delivered but not yet acked messages then we can do this, otherwise it would be more difficult. My view is we shouldn't sacrifice performance and simplicity for a non primary use case (browsing) which is generally used for management. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3994690#3994690 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3994690

19 years, 3 months

1
0
0 / 0

[Design of JBossCache] - Re: Serialization Compatibility Tests

by pavel.tsekov＠redhat.com

Manic, The database is a serialized Map object containing ClassVersionInfo objects inside it. As for the versions - on the download page (http://labs.jboss.com/portal/jbosscache/download) there are a lot of version - do we want to create a database for each of them excluding the 2.0.0 and the BETAs ? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3994687#3994687 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3994687

19 years, 3 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: JBWS-1260 - Naming for anonymous types.

by jason.greene＠jboss.com

Yeah, thats definitely wrong. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3994679#3994679 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3994679

19 years, 3 months

1
0
0 / 0

[Design of JBossCache] - Re: Last chance for any changes to the 2.0.0 API

by manik.surtani＠jboss.com

WorkspaceNodes are used by the optimistic locking interceptors so changes are not made to the nodes in the cache directly, but rather to the workspace nodes stored in the transaction workspace. NodeSPI has access to locking mechanisms that don't exist in WorkspaceNodes (since each tx will have its own copy of a workspace node, there is no concurrency here) There is no "access" to an SPI interface, as such. the SPIs are passed in to CacheLoader and CacheListener interfaces. Is there anything specific PojoCache needs from the SPI interfaces? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3994652#3994652 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3994652

19 years, 3 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: XORJoinNode

by kukeltje

cool, thanks. If you want, you can make a wiki page for this. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3994648#3994648 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3994648

19 years, 3 months

1
0
0 / 0

[Design of JBossCache] - Re: Last chance for any changes to the 2.0.0 API

by ben.wang＠jboss.com

Manik, can you explain the difference between NodeSPI and WorkspaceNode? Why are they in parallel? >From my perspective, PojoCache needs to access NodeSPI. But what about WorkspaceNode? Another question. if I stick with using the operation from Cache interface only, will there be any implication for performance reason for the new proposed change? Finally, from this hierarchy, I still don't see a clean way to access CacheSPI (or NodeSPI), except to do: CacheSPI spi = (CacheSPI)cache; But this may subject to break in the future. Should we simply add a factory method for the SPI instance? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3994641#3994641 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3994641

19 years, 3 months

1
0
0 / 0

[Design of JBossCache] - Re: Last chance for any changes to the 2.0.0 API

by manik.surtani＠jboss.com

anonymous wrote : | | This is an excellent proposal. Especially, branching off Cache from Node which was totally confusing! I would suggest to consider moving some methods from Cache to CacheSPI, like TransactionalManager and InvocationContext if possible. If you read carefully your post you already have this planned I believe. | | Some things, yes, but not all. Remember that typical end-user apps will not have access to the CacheSPI, just the Cache. Which includes things like Brian's http session repl code and Hibernate's TreeCacheProvider. Both of these would need access to the InvocationContext to set specific options. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3994632#3994632 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3994632

19 years, 3 months

1
0
0 / 0

[Design of JBossCache] - Re: Last chance for any changes to the 2.0.0 API

by manik.surtani＠jboss.com

anonymous wrote : | Also, I'd like to hear some feedback on this issue: http://jira.jboss.com/jira/browse/JBCACHE-890 . I think we may want to add a couple of flags (three already come to mind.) Multiple booleans might be sufficient for the moment. Still, having a way to extend things cleanly might be nice in 2.0. | Start a separate thread on this. I think that having such dynamically set series of flags on a node is a bit weird, wonder if we're better off with a limited set of getters/setters. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3994629#3994629 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3994629

19 years, 3 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 December 2006