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

[Design of JBossCache] - Re: String size limitations with TreeCacheMarshaller

by manik.surtani＠jboss.com

I will be using JBoss Serialization for this, so how would writeObject(String) compare (in terms of size of byte stream) to using writeUTF()? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3968399#3968399 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3968399

18 years

1
0
0 / 0

[Design of JBossXB] - Re: GenericObjectModelProvider not setting attributes in XML

by alex.loubyansky＠jboss.com

You can discuss your ideas, fixes, etc here. And use jira.jboss.com to report issues. The way the source is checked out has been changing lately. Check out this page http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossCommonProject But jbossxb moved from common/trunk/jbossxb to the top level yesterday. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3968396#3968396 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3968396

18 years

1
0
0 / 0

[Design of JBossXB] - Re: GenericObjectModelProvider not setting attributes in XML

by info＠connext.co.za

Oops, I see it is fixed in CR6. How can I get that source? Regards, Mark P Ashworth View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3968394#3968394 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3968394

18 years

1
0
0 / 0

[Design of JBossXB] - Re: GenericObjectModelProvider not setting attributes in XML

by info＠connext.co.za

Good Day, Thank you for the feedback. If I want to change / implement the functionality, how do I go about it since this is critical for our project. Regards, Mark P Ashworth View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3968393#3968393 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3968393

18 years

1
0
0 / 0

[Design of JBossCache] - Re: String size limitations with TreeCacheMarshaller

by clebert.suconic＠jboss.com

If you use writeObject(String) you won't have a limit problem. writeUTF still using a short on the beggining of a string identifying its size (from DataOutputSomewhere) On ObjectOUtputStram.writeObject it's done a check on the size of the string, and a flag it's used to defined if it's a small or a big string. In JavaOutputStream strings are treated without any metadata check, so you wouldn't have a problem calling wirteObject(String) to write these big strings. If you still want to write a chuncks of String, I had to write my own UTF parser, and on StringUtil@JBossSerialization I can also write smalls or big strings: http://fisheye.jboss.com/browse/~raw,r=1.11/JBoss/jboss-serialization/src... Clebert Suconic View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3968388#3968388 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3968388

18 years

1
0
0 / 0

[Design of JBossXB] - Re: GenericObjectModelProvider not setting attributes in XML

by alex.loubyansky＠jboss.com

You are right. I've created a jira issue and fixed it already in the SVN. http://jira.jboss.com/jira/browse/JBXB-80 As to the sources, the XB and the common module have become separate projects now and are pulled in to the thirdparty as binaries. The old sources were removed from JBoss-4.0.5.XX. Thanks. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3968385#3968385 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3968385

18 years

1
0
0 / 0

[Design of JBoss jBPM] - Re: to quartz or not to quartz

by scott.stark＠jboss.org

See the following for the discssion we had for jbossas. http://www.jboss.com/index.html?module=bb&op=viewtopic&t=78902 http://www.jboss.com/index.html?module=bb&op=viewtopic&t=85270 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3968384#3968384 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3968384

18 years

1
0
0 / 0

[Design of EJB 3.0] - Re: EJB3 issues with the Security Layer

by anil.saldhana＠jboss.com

This has been fixed. Carlo, once you are done with the RC9 release, I would like to review your security layer and remove redundancies such that changes to the JBoss Security layer does not mess your security needs. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3968379#3968379 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3968379

18 years

1
0
0 / 0

[Design of JBoss jBPM] - to quartz or not to quartz

by tom.baeyens＠jboss.com

i was really convinced of proving that i don't suffer the not invented here (NIH) syndrome. so i was going to use quartz to fix the asynchronous command and scheduler problems. In summary: the quite heavy integration layer that is necessary between quartz and jbpm (mainly jdbc connection and transaction integration) makes is more difficult to create a supportable jbpm. On the other hand, looking at quartz made me realize how we can easily upgrade our current timer/messaging mechanism to make it as robust as quartz. currently this is where i stand: i have completed the quartz customization classes to get the jdbc connection and transaction behaviour that i want: all of what follows is only intended to run on a standard java environment. for enterprise environment, we're going to build an ejb-timer-service based implementation. jBPM's timer requirements are quite basic. jBPM managed the code to be executed. The thing i need is a few basic operations to insert and cancel timers. On the other hand, i need a Job execution algorithm. * for managing jobs and triggers (user operations coming from the process definitions), the same jdbc connection should be used as for the jbpm process updates. * for quartz internal transactions, quartz should obtain its own JDBC connections and manage the transactions on those connections. There is only one job store that makes the separation between these two types of quartz transactions: JobStoreCMT. In fact, by reading that job store and related docs, i discovered that quartz needs two types of transactions, one type of transactions is for user operations and one type of transactions is for quartz internal stuff. Next i would have to write a Job that contains a reference to a jbpm action. It seems to me that i have gone through quite a bit of trouble to remove and work around the quartz behaviour that i don't need in jBPM. Most of the existing quartz knowledge cannot be used since we have to go through quite a few hoops to get it working. That integration will be quite tricky to explain to our users and to support our customers. Another downside that i see is that quartz uses it's own object to JDBC mapping. They support quite a few databases, but it reduces the chance of things running smooth out of the box. Also configuration management becomes a lot more difficult if you have to maintain the jbpm-hibernate configurations separate from the quartz configurations. Also the schema is a bit big for what we need. The question is mainly: is the part of quartz that we use worth while all this trouble. I have definitely seen a simple solution for the current problems that we currently have with our initial timer and messaging services. The trick that quartz uses is having out-of-bound transactions and/or database pessimistic locking. I have gone as far as that i can see how we can get it to work. This resulted in a lot of configurations and assumptions on how quartz is used in jBPM. So the bigest resistence i have to go for quartz is support. If we use quartz, chances are that our users will use quartz in ways that conflict with the assumptions that we have made now: responding to those inquiries and bug reports is going to take a lot of time because the debugging will be mostly in the highly customized jbpm-quartz integration. That is a level of abstraction extra versus the do-it-yourself-invented-here approach. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3968365#3968365 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3968365

18 years

1
0
0 / 0

[Design of JBossCache] - String size limitations with TreeCacheMarshaller

by manik.surtani＠jboss.com

See http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3968346 and JBCACHE-756. The story is that Strings are written using writeUTF() which has a 65535 byte limit. See: http://java.sun.com/j2se/1.5.0/docs/api/java/io/DataOutput.html#writeUTF(... While I initially thought that fixing this would: 1) Involve having to write String objects directly (inefficient) as any other form of writing a byte stream will result in hitting some limit or the other. 2) Break binary stream compat with the 1.4 series. I've expressed these in the JIRA task. Thinking about this a bit more, 1) Perhaps we can chunk Strings into several writeUTF() calls. 2 bytes can be written first, to identify how many chunks to expect. This will give us a limit of 2^16 x 2^16 bytes, or 4GB of String data (!). 2) We can make this backward-compatible by using the current format for Strings under 64kb, and a new magic number (MAGIC_NUMBER_LARGE_STRING ?) for a 'chunked' version, up to 4GB Strings. Thoughts? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3968359#3968359 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3968359

18 years

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 August 2006