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

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

by clebert.suconic＠jboss.com

Just to complete the thread... We will change the intercept method as void intercept (Packet packet) throws MessagingException And we will also change how this is configured. An user will have to enter its interceptor on the jbm-config.xml, and that interceptor will need to be available on the server side classLoader. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4124534#4124534 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4124534

16 years, 3 months

1
0
0 / 0

[Deployers on JBoss (Deployers/JBoss)] - Re: Remoting 3 deployers

by alesj

"david.lloyd(a)jboss.com" wrote : And, is it better to make a separate deployer for each type, or to have one deployer that covers everything? | I would go with separate deployer for each type. Since that was our intention with the aspect deployers. To have small fine grained easily changeable components. Perhaps follow this discussion between runtime and deployment process architecture: - http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4124055#4124055 "david.lloyd(a)jboss.com" wrote : | Finally, is it better to use JAXPDeployer/JAXBDeployer(s) or is there a more preferred way to deploy using an XML configuration? | I would go with the new thing that we will introduce: - http://anonsvn.jboss.org/repos/jbossas/projects/microcontainer/trunk/cont... - http://anonsvn.jboss.org/repos/jbossas/projects/microcontainer/trunk/cont... We already have MC bean metadata annotated, just need to switch the current BeanDeployer to use this jbossxb-builder. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4124520#4124520 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4124520

16 years, 3 months

1
0
0 / 0

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

by kukeltje

Look at: http://www.jboss.org/resources/soa All in line, compatible.... if you do not choose to use this (subscription based) you are to some extend on your own. Sometimes this includes downloading sources e.g. compiling etc... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4124488#4124488 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4124488

16 years, 3 months

1
0
0 / 0

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

by timfox

I think | public void intercept(Packet packet, Handler handler, final Sender sender) | { | handler.handle(packet, new Sender() { | public void send(Packet packet) | { | sentPacket = packet; | sender.sent(packet); | } | }; | } | Is way too complex. I think we should keep it simple like the standard old interceptors. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4124478#4124478 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4124478

16 years, 3 months

1
0
0 / 0

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

by clebert.suconic＠jboss.com

"apwalker" wrote : IMHO you should use a Packet interface rather than the AbstractPacket as the type that get passed in. I guess so should PackHandler and PacketSender if they aren't already. | We currently don't AbstractPacket implementing an interface. Should we create one? Jeff... Tim? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4124472#4124472 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4124472

16 years, 3 months

1
0
0 / 0

[Design of the JBoss EJB Container] - ADVERTENCIA: JSF1033: Resource injection is DISABLED.

by rodosa

Hello! I'm using JSF with JBoss jBPM and when JBoss server starts in the log I can see the following error: | 2008-01-28 10:20:07,703 ERROR [STDERR] 28-ene-2008 10:20:07 com.sun.faces.config.ConfigureListener c | ontextInitialized | INFO: Initializing Sun's JavaServer Faces implementation (1.2_03-b09-FCS) for context 'web_applicati | on_name' | 2008-01-28 10:20:07,984 ERROR [STDERR] 28-ene-2008 10:20:07 com.sun.faces.spi.InjectionProviderFacto | ry createInstance | ADVERTENCIA: JSF1033: Resource injection is DISABLED. | Anybody knows how I can fix it? Thanks View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4124457#4124457 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4124457

16 years, 3 months

1
0
0 / 0

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

by clebert.suconic＠jboss.com

anonymous wrote : Remember though that we won't always be running with the MC, e.g. OEM customers running embedded and directly instantiating our POJOs, so the functionality needs to work with or without the MC being available. | A simple call to MinaServrice.addFilter (or interceptor case we rename it, should be enough). We have a way around it, and it would be easy either way. anonymous wrote : Also not sure why we need PacketHandler and PacketSender passed into the method, surely: | It would be useful when you want to intercept the return value of the Handler. If we had the intercept working on both ways (client2Server and server2Client, you would never had the context of the return inside the same method). This would be like the ServletFilter where you have the InputStream and OutputStream available on the call. Case you wanted to override a return, you could something like: public void intercept(Packet packet, Handler handler, final Sender sender) | { | handler.handle(packet, new Sender() { | public void send(Packet packet) | { | sentPacket = packet; | sender.sent(packet); | } | }; | } | It would be harder to associate the sent and returned packet without this context. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4124454#4124454 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4124454

16 years, 3 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Design of Remoting 3 deployers

by david.lloyd＠jboss.com

I've started a thread in the Deployers forum about the design of the R3 deployer. The link is here: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4124437 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4124438#4124438 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4124438

16 years, 3 months

1
0
0 / 0

[Deployers on JBoss (Deployers/JBoss)] - Remoting 3 deployers

by david.lloyd＠jboss.com

I'm working on creating deployers for Remoting 3. The design I'm thinking of will allow deployment and/or configuration of: * Endpoints * Protocol support modules * Protocol server instances * Server interceptor modules * Service instances * Remote endpoint connections Each of these items should be individually deployable, but it should also be possible to deploy multiple units at once (the individual configurations are fairly simple at this point, and it would be silly to require the user to write 10 4-line XML files just to get a basic deployment running). I believe that it is most appropriate to express each of these items as a simple XML configuration. So my first question is, what is the most appropriate way to approach this deployer? And, is it better to make a separate deployer for each type, or to have one deployer that covers everything? Finally, is it better to use JAXPDeployer/JAXBDeployer(s) or is there a more preferred way to deploy using an XML configuration? It seems like every deployer in the AS codebase does something a bit different, and I've been unable to find a good example of what a deployer ought to look like. Thanks. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4124437#4124437 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4124437

16 years, 3 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: New ClassLoader initial checkin

by gcompienne

Hello Adrian, Early in the post you indicated that the classloading mechanism was in the microcontainer project but that it wasn't its rightfull place. I wonder if your opinion has changed on this topic? I must admit from my point of view I have the tendency to see the microcontainer as the main mechanism allowing you to host components/containers together. And to me this means that classloading will typically play a critical role in this. I agree that MC does not have to know the exact details (each subsystem could have its own way) but I still imagine that for things to work and cooperate the system would still need some general "rules of engagement". And these rules (things like the specification of the base CL policy mechanism) would have to be specified by MC. Then when someone writes a container it would be clear that, as long as they respect the MC rules, then they have good chances that it will work. Yes, things like classloaders could be separated from MC but then there will need to clarify the various projects that ones needs to be aware of in order to write a workable container. I must admit this is probably a simplistic view (admin tasks comes to mind) and I am still trying to get my head round MC, but still I wonder if your opinion on this has changed or not. Thanks. Gilles. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4124430#4124430 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4124430

16 years, 3 months

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 January 2008