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

[Design of Messaging on JBoss (Messaging/JBoss)] - JBMESSAGING-1225 - PacketFilters implementation

by clebert.suconic＠jboss.com

I'm adding the capability of intercepting packets on ServerSide, right before sending those to the packetHandler. This is a higher level functionality than the one provided by Mina, and this is how it works: A Customer can implement an interface defined by org.jboss.messaging.core.remoting.PacketFilter, example: | public class DummyFilter implements PacketFilter | { | public boolean filterMessage(AbstractPacket packet, PacketHandler handler, | PacketSender sender) | { | System.out.println("Packet " + packet + " intercepted); | return true; | } | | } | And by simply deploying the DummyFilter on the MicroContainer (anyway you want) will be enough to wire it on the MinaService, done automagically by the MicroContainer. (Thanks for Ales' help). Example of a deployment descriptor: | <?xml version="1.0" encoding="UTF-8"?> | <deployment xmlns="urn:jboss:bean-deployer:2.0"> | <bean name="MyFilter" class="a.b.DummyFilter"/> | </deployment> | Also, to support testing of this method, I have added back few deploy and undeploy methods to our Servers/Bootstrapserver. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4124236#4124236 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4124236

16 years, 11 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: jBPM 3.x and JBoss 4.2.x compatible enterprise EAR needs

by ryanrlamothe

Both the web console and the enterprise EAR need to be built for 4.2 compatibility. Now, it may be additional work, but why does RedHat/JBoss release JBoss AS and leave all of the other equally as important and dependent software releases in various states of compatibility disarray? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4124215#4124215 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4124215

16 years, 11 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Potential enhancement to jbpm

by brittm

anonymous wrote : jBPM does *not* do this. The application (or framework) does I was responding to argo's issue, rather than your previous post. Sorry I wasn't clear about that. Versioning... jBPM's current version scheme does a great job for what it is intended to within the jBPM library; however, from an administrative perspective there are three pieces of info that a developer or admin are very interested in having regarding every ProcessDefinition deployment: * Which version of UI requirements are needed, if any. * When was the Definition deployed (this simple timestamp can answer a lot of questions very quickly). * Is this a major release that breaks compatibility, or is it a minor release that simply addresses a small bug, typo, etc. These three pieces of info are pretty important for management of a large application--and they are simple--just three fields that ought to live on the ProcessDefinition itself. The developer can apply any standard for versioning and can use the data any way he sees fit. <processdefinition name='myDef' release='1.12.4' ui='1.8' > Since the meta data is purely user supplied and user consumed, jBPM should not bother with any type of comparison or validation. It just needs to store it. No compatibility issues. On the topic of UI requirements: Two types of screen requirement versioning are appropriate--one at the process level for summary screens, and one at the task level for task screens. So, we would also apply ui= to the task entry as well: <task name='myTask' ui='1.9'> ProcessDefinition ui= can be used to apply screen requirement versioning to process summary screens, or to apply screen versioning to tasks across the board. Task ui= can be used to apply screen requirement versioning on a task by task basis if that level of detail is desirable. This solution would provide a needed mapping in a place where it is easiest to apply and use, and still keeps UI concerns at arms length from the process defintion. We're only acknowledging that there is a UI requirement for this process/task and referencing that requirement at the highest level. When the solution can be so simple, it seems a shame to not provide for a user request that has become so common. If this is a lowest-common-denominator solution that doesn't raise major objections, I'll create a JIRA issue for it. I may also be able to provide an implementation if my current schedule permits, but that's not a promise. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4124212#4124212 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4124212

16 years, 11 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Nice version conlfict on jboss-ejb3-ext-api-impl

by bstansberry＠jboss.com

No need for a new ha-client release; the one you want is already there (1.0.0.BETA2), just needs build/build-thirdparty.xml to specify it once ejb3 can properly use it. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4124137#4124137 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4124137

16 years, 11 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Nice version conlfict on jboss-ejb3-ext-api-impl

by ALRubinger

And I'll be cutting new releases of ejb3-ext-api, ejb3-ext-api-impl, and ha-client for Beta4. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4124128#4124128 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4124128

16 years, 11 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Nice version conlfict on jboss-ejb3-ext-api-impl

by wolfc

ejb3-ext-api-impl should slowly disappear as we put annotation implementations within their respective components. So ClusteredImpl should be in with the code that instantiates it. @Clustered is part of ejb3-ext-api. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4124124#4124124 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4124124

16 years, 11 months

1
0
0 / 0

[Design of POJO Server] - Re: Domain interaction when there is scoping

by scott.stark＠jboss.org

So is this something you will do? I was not expecting this for beta4. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4124121#4124121 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4124121

16 years, 11 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: how to define global variables for process in xml

by kukeltje

this is a question for the User forum, not the dev forum View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4124113#4124113 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4124113

16 years, 11 months

1
0
0 / 0

[Design of JBoss Portal] - Re: Portlet taglib + test case

by chris.laprun＠jboss.com

Thanks. I will try these solutions today. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4124109#4124109 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4124109

16 years, 11 months

1
0
0 / 0

[Design of JBoss/Tomcat Integration] - Re: Tomcat Deployer is wrong in JBoss Head

by bstansberry＠jboss.com

I'd thought about this separation of the deployment chain and the runtime a while back. AFAICT it seemed quite simple; looked like the different functionality in TomcatDeployer was largely separated into different methods, with the stuff related to controlling the webserver lifecycle encapsulated into create/start/stop/destroy and the deployment stuff quite separate. The only common bit I saw was the fact that both sides were interested in conf/web.xml. As long as that resource was in a location visible to both deploy and deployers, it might just be a matter of splitting the class. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4124093#4124093 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4124093

16 years, 11 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 January 2008