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

[Design of JBoss/Tomcat Integration] - Re: JBAS-5673 - Metadata processing

by scott.stark＠jboss.org

"emuckenhuber" wrote : | Hmm that's because of a request of the WS team, when we added the @WebServiceRef processing - i can talk to them again and see if we can fix that ? I don't know that its wrong, its just inconsistent with other reference usage. It should be documented so one understands that doing a lookup against the ref name it going to fail. How this name is used is the question. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169111#4169111 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169111

17 years, 5 months

1
0
0 / 0

[Design of JBoss Profiler] - Re: Problem with JBoss Profiler 2 Beta install.

by aprobe

OK, I found the problem. I was not starting JBoss from the bin directory and I did not have a full path to the jboss-profiler.jar file in the JAVA_OPTS. Fixing that gets things going. Do I need to add a path to the jboss-profiler.properties -D options as well? Also, I notice there is such a file in the jboss-profiler.jar file as well as the one I put in the put directory. Which one gets used? Now I have problem with the profiler communications. I get a NoClassDefFoundError for org/jboss/remoting/ServerInvocationHandler during startup, and I can't connect with the client. I assume I am missing some jar file, but which one? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169109#4169109 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169109

17 years, 5 months

1
0
0 / 0

[Design of JBoss Profiler] - Re: Problem with JBoss Profiler 2 Beta install.

by aprobe

OK, I downloaded and built the profiler locally, moved the jar and sar files to the proper positions, but I still get the same failure. I rechecked the jboss-profiler.jar file with "jar tf ..." and it looks fine to me. What next? Do I need to do somehting with the classpath? I tried adding the jboss-profiler.jar (and others) to the classpath bu that doesn't help. I removed the jboss-profiler.jar file form the bin directory and I get the same error, so there must be something wrong with the classpath or some other definition that locates the jar file. Ideas? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169107#4169107 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169107

17 years, 5 months

1
0
0 / 0

[Design of JBossCache] - Re: Common marshalling infrastructure

by manik.surtani＠jboss.com

Ok, all sounds good so far. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169103#4169103 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169103

17 years, 5 months

1
0
0 / 0

[Design of Clustering on JBoss] - Re: JBCLUSTER-206 - Extract HB/JBC integration layer from EJ

by galder.zamarreno＠jboss.com

I'm back :) Local puts only enhancement is now coded, tested and committed. Switched the tests to READ_COMMITTED. Removed *Hook from the cache provider names. I'll now work on the integration part so that Prabhat can start testing asap. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169090#4169090 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169090

17 years, 5 months

1
0
0 / 0

[Design of JBossCache] - Re: Common marshalling infrastructure

by david.lloyd＠jboss.com

"manik.surtani(a)jboss.com" wrote : Re: ref counting, I understand about class data, but as long as instance data is also only written once then that is fine. | | Re: version headers, perhaps I could swap ObjectMarshallers midway? | | e.g., | | | | Map<Short, ObjectMarshaller> objectMarshallers = ... ; | | ByteInput in = new ByteBufferByteInputAdapter(byteBuffer); | | unmarshaller.start(in); | | short versionId = (Short) unmarshaller.readObjectUnshared(); | | unmarshaller.setObjectMarshaller( objectMarshallers.get(versionId) ); | | // ... | | // continue unmarshalling rest of my state | | // ... | | | | | Doing a readObject just to get a number could be overkill, maybe something simpler: | Map<Short, MarshallerFactory> marshallers = ...; | ByteInput in = ... | int magic = in.get() << 8 | in.get(); | Unmarshaller unmarshaller = marshallers.get(Short.valueOf(magic)).createUnmarshaller(); | // use unmarshaller to read your state | "manik.surtani(a)jboss.com" wrote : And when marshalling how would object marshallers be selected? I'm guessing a preference for anything that uses magic numbers (how would you denote that an internal class - which *may* implement Externalizable as well - should be marshalled based on a magic number? Another marker interface, perhaps? Or a sub-interface to Externalizable - Marshallable? And if this is not present then test for Externalizable, and then Serializable, etc., and finally falling back to an Externalizer? The default (I guess) ObjectMarshaller would look for an Externalizer for that object, and if it's found, it would use that, otherwise it would follow the rules for object serialization as they are specified by the JDK. A subclass might add a "tag" byte that says "this is an already-known instance" and return a preset instance. The default ClassMarshaller would work similarly - it would write a class descriptor per the JDK spec. Similarly a subclass might write a tag byte and magic number for preset classes. If the object is not a pre-known instance, an ObjectMarshaller or ClassMarshaller could write an "unknown" tag byte and would delegate to the default instance of that interface to take the default action. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169089#4169089 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169089

17 years, 5 months

1
0
0 / 0

[Design of JBossCache] - Re: Common marshalling infrastructure

by manik.surtani＠jboss.com

Re: ref counting, I understand about class data, but as long as instance data is also only written once then that is fine. Re: version headers, perhaps I could swap ObjectMarshallers midway? e.g., | Map<Short, ObjectMarshaller> objectMarshallers = ... ; | ByteInput in = new ByteBufferByteInputAdapter(byteBuffer); | unmarshaller.start(in); | short versionId = (Short) unmarshaller.readObjectUnshared(); | unmarshaller.setObjectMarshaller( objectMarshallers.get(versionId) ); | // ... | // continue unmarshalling rest of my state | // ... | | And when marshalling how would object marshallers be selected? I'm guessing a preference for anything that uses magic numbers (how would you denote that an internal class - which *may* implement Externalizable as well - should be marshalled based on a magic number? Another marker interface, perhaps? Or a sub-interface to Externalizable - Marshallable? And if this is not present then test for Externalizable, and then Serializable, etc., and finally falling back to an Externalizer? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169086#4169086 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169086

17 years, 5 months

1
0
0 / 0

[Design of JBossCache] - Re: Common marshalling infrastructure

by david.lloyd＠jboss.com

"manik.surtani(a)jboss.com" wrote : * Reference counting. Do you propose any sort of ref counting, if I were to write the same instance to the stream multiple times? No, I hadn't planned on it - what do you have in mind? The instance and class cache would take care of making sure that full class/instance data is written to the stream only one time, if that's what you're getting at. There's no reference counting involved or anything like that though. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169082#4169082 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169082

17 years, 5 months

1
0
0 / 0

[Design of JBossCache] - Re: Common marshalling infrastructure

by david.lloyd＠jboss.com

"manik.surtani(a)jboss.com" wrote : * How are ObjectMarshallers selected? Based on the class info from the ClassMarshaller? Could this be ClassMarshaller + some token from the StreamHeader? (see previous point for reason why) You'd configure your MarshallerFactory to use a specific ObjectMarshaller. The ObjectMarshaller is generally responsible for the wire format of the stream as well as object instance pooling. The current design expects you to select your marshaller before you start reading... I didn't think of the case where you want to somehow detect it. I guess the thing to do in this case is write a bit of code that reads the header, determines the marshaller to use, and then connects the stream to that header? I'm not sure there's a clean way to integrate detection that wouldn't be more easily done outside of the framework. I'll think about it some more, or if you have any ideas...? "manik.surtani(a)jboss.com" wrote : * Pooling MOIS and MOOS - probably will have to happen due to the cost of constructing these, and if they are reused, why would you discard the Object and Cache Marshallers from the Marshaller? You want to dump your instance and class caches on every "session". The Object/ClassMarshallers should be very cheap to construct (basically building an empty hashmap on write, or an empty arraylist on read). The Marshallers *should* be decoupled from MOIS/MOOS usually; I would expect that an implementation would be able implement pooling of these instances if needed. Note that even if you retain 100% JDK compatibility, if you never serialize an object that has readObject/writeObject methods, then you never even need to have a MOIS/MOOS at all, so that's the cheapest cost possible. :-) In other words, if you use Externalizable, Externalizer, and default serialization exclusively, then the cost is never incurred. Also keep in mind that constructing MOIS/MOOS are not *as* expensive as standard Object*Streams because they use the alternate "build my own implementation" constructor which just nulls out most of the fields. However there is still the issue of a security check on each construction, which may or may not be significant. * Reference counting. Do you propose any sort of ref counting, if I were to write the same instance to the stream multiple times? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169081#4169081 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169081

17 years, 5 months

1
0
0 / 0

[Design of JBossCache] - Re: Common marshalling infrastructure

by manik.surtani＠jboss.com

"manik.surtani(a)jboss.com" wrote : | * ByteInput and ByteOutput - could they be compatible with org.jboss.cache.io.ByteBuffer? Essentially this class is an extension of org.jgroups.util.Buffer, which provides direct access to a byte array. I'd hate to have to copy things around to use these new interfaces. | Ignore this, I just noticed that ByteInput and ByteOutput are interfaces and I can implement stuff that talks to ByteBuffer. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169078#4169078 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169078

17 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 August 2008