September 2006 - jboss-dev-forums

[Design of POJO Server] - Re: Hot deploying deployers - deployer chains

by scott.stark＠jboss.org

So are we going to address an spi change before moving this to trunk? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972980#3972980 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972980

19 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: Updating docs

by scott.stark＠jboss.org

Yes, this was the conclusion reached with the network team. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972978#3972978 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972978

19 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: Deployers and classloading - stumbling block

by scott.stark＠jboss.org

Ok, I have seen the current changes. What I am currently working on is validating scoped service deployments as this is needed for jboss messasging. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972977#3972977 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972977

19 years, 6 months

1
0
0 / 0

[Design of EJB 3.0] - Re: @EJB Injection Not Working

by ALRubinger

Thanks so much, Stephan. Where did you find that? javax.ejb.EJB lives in RC9's jboss-ejb3x.jar. When running the patch installer, this file gets updated in $JBOSS_HOME/server/[instancename]/deploy/ejb3.deployer, but not $JBOSS_HOME/client. Intentional? I will update the Migration Wiki at http://wiki.jboss.org/wiki/Wiki.jsp?page=FromRC8RC9. Thanks again. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972973#3972973 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972973

19 years, 6 months

1
0
0 / 0

[Design of JBoss jBPM] - get suspended tasksinstances

by asmo

Hi! is there a way to get all taskinstance of an actor, not only the unfinished , also the finished taskinstances? Thank you! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972972#3972972 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972972

19 years, 6 months

1
0
0 / 0

[Design of JBoss Portal] - Re: WANTED: Input from administrators & developers

by dhartford

anonymous wrote : I am not sure to get this right, the "CMS server" is already quite independent (it is JackRabbit) with a homebrew Hibernate storage. | This could be interesting to discuss over the phone during a conf call. I am not even sure you and jewhit are talking about the exact same thing. Please email me if you are interested by a call, same for jewhit. jewhit and I may have different ideas/goals, not sure. Nonetheless, Jackrabbit was the path I was going down anyway -- and as of yesterday Jukka released a 1.1-rc1 with a compatible JCA adaptor making this a lot easier. As for independent, I guess I always see portal and the repo(jackrabbit) installed together, and it may be nice to have them seperate with a 'combo' install for those that do want them installed from one package. One 'Jboss Repo' package for Jackrabbit JCA, JCR support, WebDAV support, and the jboss hibernate wrapper (Shotoku I assume), possibly with their own admin tools (i.e. repo security/access, storage sizing, storage locations on local disk, iSCSI, SAN, etc, backup utilities, more). From the Provisioning side, I think the seperation of the portal and the repo would help out a lot, as well as add another service layer available to developers related to file-based/non-relationalDB storage. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972939#3972939 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972939

19 years, 6 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Action Processing Pipelines, updated Trailblazer etc...

by tfennelly

"kurt.stam(a)jboss.com" wrote : Yes the banks are using XStream, they are standalone bank applications. Why is the loanbroker now using XStream? We should be using our own marshalling implementation, why was this changed? I'm afraid I can't answer that one Kurt!! I just checked ProcessCreditResponse.java in the beta1 release and I can see now how this was able to work before. See in the sendJMSToBank method - it registers an alias such that org.jboss.soa.esb.samples.loanbroker.banks.BanksQuoteRequest gets mapped to org.jboss.soa.esb.samples.loanbroker.banks.BankQuoteRequest. Look really hard and you'll spot the difference. ObjectToXStream just uses the class name of the object passed in. So, we can either remove XStream from one end or the other, or leave things as they are. There's no point going back to the beta1 way of doing things because that's no less confusing than it is now. I'd go for removing XStream from the Bank code because ObjectToXStream is an OK demo of how to write reusable action processors. The demo isn't really about how to write banking systems using XStream. "kurt.stam(a)jboss.com" wrote : | The BankQuoteRequest should not be the same class. These are independent systems and this will make the demo code confusing I think. +1 Sounds like something to be added to JIRA :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972925#3972925 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972925

19 years, 6 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Action Processing Pipelines, updated Trailblazer etc...

by kurt.stam＠jboss.com

Yes the banks are using XStream, they are standalone bank applications. Why is the loanbroker now using XStream? We should be using our own marshalling implementation, why was this changed? The BankQuoteRequest should not be the same class. These are independent systems and this will make the demo code confusing I think. --Kurt View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972918#3972918 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972918

19 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: Updating docs

by adrian＠jboss.org

"scott.stark(a)jboss.org" wrote : Possibly, but my concern with this is its pushing too many management details to the bean developers. | On the contrary, keeping the two together is the only way it is going to remain in anyway in synch. I do see the need for being able to override what the bean developer thought (or didn't think) was a good idea. Or maybe just plain forgot, thus requiring retrofitting the description. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972902#3972902 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972902

19 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: Deployers and classloading - stumbling block

by adrian＠jboss.org

I've implemented this by splitting it up into three sections: * bootstrap - conf/jboss-service.xml * deployers - server/config/deployers * deployments - server/config/deploy To prove it works, I've also got hacky but working versions of the RARDeployer and ConnectionFactory deployer in JCA. So we now have datasources and (as a consequence) jbossmq working. The biggest hack is deciding what should be the thread context classloader for the bootstrap (like the old server loader did). For now, I'm using the "first" bootstrap deployment's classloader which is ok in this case because there is only one. Of course when the deployers have their own classloaders this will be a none issue. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972901#3972901 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972901

19 years, 6 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 September 2006