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

[Design of JBossXB] - Re: SundayContentHandler: Don't add collections into collect

by adrian＠jboss.org

I was seeing error messages like: java.lang.ClassCastExeption: ArrayList at myCollecton.add ... i.e. It was creating a new ArrayList, then trying to add it into the parent collection instead of using the parent collection as a collection. I tracked the problem down to where the ValueList always created a new ArrayList. Avoiding constructing of the ValueList meant it uses my collection as a collection. NOTE: This was a generic (it checks the types on add hence the ClassCast) custom collection. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977238#3977238 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977238

19 years, 6 months

1
0
0 / 0

[Design of JBoss Admin Console] - Problem Displaying the Applet in the web console

by myplanet

Hi I installed Jboss in my Computer .. When I use this Url: http://localhost:8080/web-console/ I can't see the applet in the left side of the console The error is: class org.jboss.navtree.appletbrowser not found Can you help me ?? Thanks View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977226#3977226 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977226

19 years, 6 months

1
0
0 / 0

[Design of JBossXB] - Still got problems with groups

by adrian＠jboss.org

I still have an issue mapping groups. This relates to the work being done here: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=92129 It is relatively easy to map elements/types, since if you have: | xsd: | <xsd:type name="parent"> | <complexType> | <sequence> | <xsd:element ref="child"/> | </sequence> | </complexType> | </xsd:type> | | xml: | <parent> | <child/> | </parent> | | java | @SchemaType(name="parent") | public class ParentType | { | @SchemaProperty(name="child") | public String whatever; | } | You can just add an interceptor. I currently have two generic interceptors: 1) For plain properties 2) For collection properties These are generalisations of the interceptors I have written before in bean schema binding. However for a group what you want to do is create buckets/holders, e.g. | xsd: | <xsd:group name="parent"> | <sequence> | <xsd:element ref="element1" maxOccurs="unbound"/> | <xsd:element ref="element2" maxOccurs="unbound"/> | <xsd:element ref="element3" maxOccurs="unbound"/> | </sequence> | </complexType> | </xsd:type> | | xml: | <parent> | <element1/> | <element1/> | <element2/> | <element3/> | </parent> | | java | @SchemaType(name="parent") | public class ParentType | { | @SchemaHolder(name="element1") | public Bucket1 b1; | @SchemaHolder(name="element2") | public Bucket1 b1; | @SchemaHolder(name="element3") | public Bucket1 b1; | } | I originally tried to do this a custom particle handler on the group that extended and delegated to the default handler which basically replaced the parent object with the relevant bucket. But this has two problems that boil down to the same problem: 1) The information you get at the end does not tell you which bucket finished. 2) The particle handler is only invoked at the beginning and end of the group, not the beginning and end of the buckets/subparticles. So currently, it doesn't seem like there is anyway other than to add metadata to the elements to get this bucket processing. But this fails, because if like the example above, the elements are global, you may be using the element somewhere else than the group. In fact, there is a way. It basically means looking at all types and elements that use the group and adding interecptors for the buckets to each type and element found. This isn't very nice and seems like a hack to me. I'd prefer it, if it was possible to just add metadata/interceptors to the group that would automatically get used by referencing types/elements as it went through the stack/model during parsing. P.S. To explain the idea of a "SchemaHolder" This is intended to introduce something into the xml model that isn't really there, but it is in the java model. If it were, the xml would be written like: | <parent> | <bucket1> | <element1/> | <element1/> | </bucket1> | etc. | The holder/bucket can be either collection or plain java type. Also potentially in future, the holder might completely rework the object into a different type for injection onto the parent. e.g. The holder is a collection, but the parent has been "denormalized" | public class Holder | { | public Collection<Element> elements; | } | public class Parent | { | public Element1 e1; | public Element2 e2; | } | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977225#3977225 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977225

19 years, 6 months

1
0
0 / 0

[Design of JBossXB] - SundayContentHandler: Don't add collections into collections

by alex.loubyansky＠jboss.com

Why not? Modified: jbossxb/trunk/src/main/java/org/jboss/xb/binding/sunday/unmarshalling/SundayContentHandler.java =================================================================== --- jbossxb/trunk/src/main/java/org/jboss/xb/binding/sunday/unmarshalling/SundayContentHandler.java 2006-10-10 12:16:10 UTC (rev 2114) +++ jbossxb/trunk/src/main/java/org/jboss/xb/binding/sunday/unmarshalling/SundayContentHandler.java 2006-10-10 12:16:40 UTC (rev 2115) @@ -652,6 +652,7 @@ StackItem item = stack.peek(); if(item.o != null && !(item.o instanceof GenericValueContainer) && + (item.o instanceof Collection == false) && term.getAddMethodMetaData() == null && term.getMapEntryMetaData() == null && term.getPutMethodMetaData() == null) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977218#3977218 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977218

19 years, 6 months

1
0
0 / 0

[Design of JBossXB] - Re: Using annotations to define schema mappings

by adrian＠jboss.org

I think overridding annotations would be relatively trivial in XsdBinder. I don't know that it could use real XPath though since Xerces' XSModel is not a DOM model. It is more what the xml specs call an "information set", but don't know it is formal enough to apply this: http://www.w3.org/TR/xpath#infoset View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977215#3977215 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977215

19 years, 6 months

1
0
0 / 0

[Design of JBossXB] - Re: Top level groups

by adrian＠jboss.org

I also broke the particles for top level groups where it was processing them multiple times. Once at the top level then again when the group got referenced. I've fixed it by only processing group particles when the group doesn't have any, but there is probably a better way to do this? e.g. | +if (groupBinding.getParticles().isEmpty()) | +{ | ctx.pushModelGroup(groupBinding); | bindModelGroupParticles(ctx, group); | ctx.popModelGroup(); | +} | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977211#3977211 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977211

19 years, 6 months

1
0
0 / 0

[Design of JBossXB] - Re: Top level groups

by adrian＠jboss.org

Sorry, yes, it should EMPTY_SET unless you are going to use jboss retro and convert JBossXB to use java 5. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977210#3977210 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977210

19 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Once and only once delivery?

by timfox

I suspect this would make sense to only implement for persistent messages, since duplicate detection would be an extra QoS over and above that provided by persistent messages. The sweeping is an interesting although you only really want to retain the ids, not the entire message or message reference so this could be wasteful in terms of storage. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977207#3977207 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977207

19 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Once and only once delivery?

by apwalker

If you only wanted this feature for persisted messages then you could change the client receive not to actually remove the message from the DB but flag it as being read. Then the you could just check if the message already existed before writing it to the DB. You could then just periodcally sweep and delete the read messages Just a thought...... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977194#3977194 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977194

19 years, 6 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: ProcessDefinition with no startTask

by tom.baeyens＠jboss.com

yes. both should be supported. A ProcessDefinition with no start task should not have a link in the webapp to start the process. At least not from the normal task management interface. It might be possible to start such a process as an admin type of functionality. But the latter is certainly some time in the future. A ProcessDefinition with start task without a related form. That means that users actually are able to start the process without needing to feed data into it. In case the start state has multiple leaving transitions, the user will have to select the desired transition. So it might result into a form without data input, but with one button for each leaving transition. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977178#3977178 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977178

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