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

[Design of JBossCache] - Re: Common marshalling infrastructure

by manik.surtani＠jboss.com

Looks good and well thought out. A couple of questions: * 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. * StreamHeader is useful for me since I need to add version bits to the stream such that the receiving end can use the appropriate marshaller implementation based on the version. * 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) * 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? * 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=4169077#4169077 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169077

17 years, 4 months

1
0
0 / 0

[Design of JBossCache] - Re: Common marshalling infrastructure

by david.lloyd＠jboss.com

"jason.greene(a)jboss.com" wrote : This looks great to me. So essentially cache would define a ClassMarshaller which would use magic numbers, and also an Externalizer for the classes those numbers represent. Then it would use an ObjectMarshaller to actually build the byte array. Actually to build the byte array you could just implement ByteOutput and pass your implementation in to Marshaller.start(). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169076#4169076 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169076

17 years, 4 months

1
0
0 / 0

[Design of JBossCache] - Re: Common marshalling infrastructure

by david.lloyd＠jboss.com

I've changed the Externalizer in trunk so that there's an ExternalizerFactory which returns an Externalizer given a Class, or null if there is none. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169075#4169075 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169075

17 years, 4 months

1
0
0 / 0

[Design of JBossCache] - Re: Common marshalling infrastructure

by jason.greene＠jboss.com

This looks great to me. So essentially cache would define a ClassMarshaller which would use magic numbers, and also an Externalizer for the classes those numbers represent. Then an ObjectMarshaller to actually build the byte array. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169069#4169069 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169069

17 years, 4 months

1
0
0 / 0

[Design of JBoss ESB] - JBossESB 4.4 GA has been released

by Kevin.Conner＠jboss.com

The team are delighted to announce the availability of our latest release, now available for download from our project download page (http://www.jboss.org/jbossesb/downloads). This release will form the basis of the next SOA platform release (4.3 GA) which should be due around September. Please download the release and let us know what you think. Kev View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169068#4169068 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169068

17 years, 4 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: StructureContext and candidate annotations

by adrian＠jboss.org

"alesj" wrote : | Unless I access parent context's callbacks. | Which is too impl specific - ear contains jars notion. Why would you want to run your own callbacks, you would just execute the code directly. ;-) I'll leave it to you on how much of a generic framework you want to put in place for a parent "interfering" with child structure. It could easily be "over-engineered", with callbacks for every critical decision in structure determination that nobody uses and instead just leads to extra complication and bugs. To be honest I can't guess how many other use cases there are or will be in future, either from the javaee spec committees or users. My preference would be to have a simple "template" that can be extended as new requirements are identified. Refactoring ever policy decision of the structure deployers into protected methods so users can subclass and add/change behaviour, (e.g. add their own callbacks) would help with "forward compatiblity", but its not something that needs to be done immediately. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169062#4169062 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169062

17 years, 4 months

1
0
0 / 0

[Design of POJO Server] - Re: ProfileService equiv to ServiceBindingManager

by bstansberry＠jboss.com

Re: the bootstap: Brian smacks head! Yes, of course. So this is a temporary issue. :-) A key becomes getting https://jira.jboss.org/jira/browse/JBAS-5349 done so we can safely move stuff out of conf/jboss-service.xml. IMO that one should be marked critical for CR2, even if we don't move anything out of conf/jboss-service.xml for 5.0.0. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169060#4169060 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169060

17 years, 4 months

1
0
0 / 0

[Design of POJO Server] - Re: Integrating aop-mc-int bean metadata with AS5

by kabir.khan＠jboss.com

I'll try to explain exactly what I am doing first. I need to do a few things in my POST_CLASSLOADER deployer org.jboss.aop.asintegration.jboss5.AbstractAopMetaDataDeployer, which handles the beans from the -aop.xml (or AOP annotations): 1) I set the correct name of the AspectManager bean to use for the beans installing aop artifacts, this is the one from conf/aop.xml if a "global" deployment. In the case of a scoped deployment, I register a new aop Domain, register that as a bean in the MC, and use it's name. 2) I also need to make sure that the pointcut expressions are deployed before any of the classes are loaded. I am currently deploying all the beanmetadata from -aop.xml myself at this stage, and stripping them out of the deployment so that they are not deployed again by BeanMetaDataDeployer. This might be overkill, maybe I should just install the pointcuts directly and allow the later deployers to install my beans as normal? I am using similar code to BeanMetaDataDeployer to deploy the beans from my deployer. 3) If it is a scoped deployment, I modify the names of the installed beans before deploying them, and add an alias using the original name, so that the aliases/original names of the aspects can still be used when injected into the bindings. I then add an annotation so that the PreInstallaction deploys the beans into a scoped controller for that deployment. As far as I can remember from my chat with Ales, although you can have beans with the same name in sibling scopes, we also have the scenario where a scoped deployment deploys an aspect with the same name in both the "global" scope and in the "scoped" scope. The aliases/unique names are used so that AbstractController.uninstall() knows which exact bean to uninstall on undeployment. Maybe the stuff you mention about the integration between the MDR and the scoped controllers is the underlying problem? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169058#4169058 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169058

17 years, 4 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: StructureContext and candidate annotations

by alesj

"adrian(a)jboss.org" wrote : | Then JARStructure does something like: | | | | if (annotationScanningEnabled && deploymentRecognised && annotationPresent) | | { | | addChild(); | | context.runAnnotationScanningCallbacks(context, env); | | } | | | This 'visitor pattern' definitely looks better. But in this case the context used in JARStructure looks useless to me, since I don't have any access to it from EARStructure code - in EARStructure::scanEar. Unless I access parent context's callbacks. Which is too impl specific - ear contains jars notion. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169055#4169055 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169055

17 years, 4 months

1
0
0 / 0

[Design of POJO Server] - Re: ProfileService equiv to ServiceBindingManager

by adrian＠jboss.org

"bstansberry(a)jboss.com" wrote : In particular, for those unwilling to stay awake through my voluminous prose Nice docs, although I made no attempt to read all the details. I'd be very impressed if you're testsuite has the same coverage. ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169054#4169054 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169054

17 years, 4 months

1
0
0 / 0

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