June 2007 - jboss-dev-forums - Jboss List Archives

[JBoss Portal Documentation] - Re: Quickstart Guide 2.6 update

by cdelashmutt

I'm trying to find out what stage things are at with the quickstart guide. I see that some work has been done to rev up the guide to 2.6, but I wanted to see where help is needed before diving into this. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4058431#4058431 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4058431

18 years, 9 months

1
0
0 / 0

[JBoss Portal Documentation] - Re: Quickstart Guide 2.6 update

by julien＠jboss.com

Please declare what you are doing on it here. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4058429#4058429 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4058429

18 years, 9 months

1
0
0 / 0

[JBoss Portal Documentation] - Quickstart Guide 2.6 update

by julien＠jboss.com

here View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4058426#4058426 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4058426

18 years, 9 months

1
0
0 / 0

[JBoss Portal Documentation] - Re: Reference Guide 2.6 update

by julien＠jboss.com

Linux does not support screenshots by default ? what is the problem, it downgrades pictures ? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4058424#4058424 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4058424

18 years, 9 months

1
0
0 / 0

[Design of JBoss Profiler] - Re: I want to extend the fucntions of profiling Java applica

by clebert.suconic＠jboss.com

We should have a way to use the JMX console out of JRE. I know there is such thing but I never tried myself... I will do some googling about MBeans, JMS and JRE later tonight. Using kill -3 is not a good approach as some platforms (windows) don't have such support. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4058400#4058400 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4058400

18 years, 9 months

1
0
0 / 0

[Design of JBoss Profiler] - Re: Building on Suse 9.3

by clebert.suconic＠jboss.com

I remember having a suse directory... I don't know what happened.. maybe I probably missed something :-(... sorry about that. I think the compile.sh under linux or linux64 should work on Suse.. but I'm not sure... I would be able to help you if you try it out. Maybe you could try CVS... but the download package should work. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4058397#4058397 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4058397

18 years, 9 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: WARNING: Deployer changes

by adrian＠jboss.org

Arghh!!! I was trying to finish off uploading snapshots and my build is broken again :-( I did deployers-impl and deployers-vfs-spi then when I tried deployers-vfs I get this. | Missing: | ---------- | 1) org.jboss.microcontainer:jboss-classloader:jar:2.0.0-SNAPSHOT | | Try downloading the file manually from the project website. | | Then, install it using the command: | mvn install:install-file -DgroupId=org.jboss.microcontainer -DartifactId=jboss-classloader \ | -Dversion=2.0.0-20070627.190928-1 -Dpackaging=jar -Dfile=/path/to/file | | Path to dependency: | 1) org.jboss.microcontainer:jboss-deployers-vfs:jar:2.0.0-SNAPSHOT | 2) org.jboss.microcontainer:jboss-deployers-impl:jar:2.0.0-SNAPSHOT | 3) org.jboss.microcontainer:jboss-classloader:jar:2.0.0-20070627.190928-1 | | 2) org.jboss.microcontainer:jboss-deployers-spi:jar:2.0.0-SNAPSHOT | | Try downloading the file manually from the project website. | | Then, install it using the command: | mvn install:install-file -DgroupId=org.jboss.microcontainer -DartifactId=jboss-deployers-spi \ | -Dversion=2.0.0-20070627.190928-1 -Dpackaging=jar -Dfile=/path/to/file | | Path to dependency: | 1) org.jboss.microcontainer:jboss-deployers-vfs:jar:2.0.0-SNAPSHOT | 2) org.jboss.microcontainer:jboss-deployers-impl:jar:2.0.0-SNAPSHOT | 3) org.jboss.microcontainer:jboss-deployers-spi:jar:2.0.0-20070627.190928-1 | | ---------- | 2 required artifacts are missing. | | for artifact: | org.jboss.microcontainer:jboss-deployers-vfs:jar:2.0.0-SNAPSHOT | I'm going to leave it until tomorrow. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4058393#4058393 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4058393

18 years, 9 months

1
0
0 / 0

[Design of JBoss Build System] - Re: Tracking subprojects

by pgier

"scott.stark(a)jboss.org" wrote : | I don't suppose jira has any support for subprojects and artifacts? | Not sure if JIRA supports subprojects, looks like they might still be working on this feature (http://jira.atlassian.com/browse/JRA-12241). Can we just use different components for the subprojects? That's basically how I have organized JBBUILD in Jira. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4058382#4058382 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4058382

18 years, 9 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: Setting the properties on the JAXBContext

by tfennelly

OK, so after looking this a bit more, I still think we're good. Haven't made it all the way yet - have other issues. I just wanted to give ye a heads up Vs waiting until tomorrow. Some feedback on the SPI changes, specifically being able to reset the JAXBHandler via the Endpoint instance.... If I were you guys, I'd be a little scared of allowing something like the ESB (JBossWSAdapter) to do this. It's true that in many cases the JBossWSAdapter will only be doing this for endpoints that are "under it's control" from a deployment perspective. However, it's not impossible to use the JBossWSAdapter to access a webservice endpoint not under it's control (from a deployment perspective). In a situation like this, isn't it a bit dodgy to be allowing the JBossWSAdapter screw with details of an endpoint not "under its control". Perhaps it'd be better to only allow programmatic "overriding" of the installed JAXBHandler via the InvocationContext i.e. only on a per request basis. That's just something for you guys to decide on. I think I have it working for the ESB so I'm happy enough from that perspective, although I did have to implement a bit of a hack in an effort to avoid the above scenario (more below). This is just general API feedback. I'm trying to avoid the type scenario I outlined above by using the old reliable ThreadLocal (Grrrr) | private static class JBossESBJBossWSJAXBHandler implements JAXBHandler { | private static ThreadLocal<JAXBHandler> handlerTL = | new ThreadLocal<JAXBHandler>(); | private JAXBHandler installedJaxbHandler; | private JBossWSAdapter adapter; | | private JBossESBJBossWSJAXBHandler( | JAXBHandler installedJaxbHandler, JBossWSAdapter adapter) { | this.installedJaxbHandler = installedJaxbHandler; | this.adapter = adapter; | handlerTL.set(installedJaxbHandler); | } | | public JAXBContext getJAXBContext(Class[] classes) throws JAXBException { | return handlerTL.get().getJAXBContext(classes); | } | | /** | * This method helps ensure that only threads executing out of the | * JBossWSAdapter are supplied with JAXBContext instances from the | * JBossWSAdapter. We don't like the idea of not using the installed | * JAXBHandler for non ESB initiated JBossWS requests after the | * JBossWSAdapter has changed the JAXBHandler for the endpoint. | */ | private void useAdapterAsHandler() { | handlerTL.set(adapter); | } | | private void useInstalledHandler() { | handlerTL.set(installedJaxbHandler); | } | } | So the JBossWSAdapter is my real JAXBHandler and the class outlined above is just a way of toggling between the installed JAXBHandler and the JBossWSAdapter JAXBHandler via the useInstalledHandler and useAdapterAsHandler methods respectively. The JBossWSAdapter turns itself on as the handler for the current thread and when done turns itself off and switches the thread back to the installed handler. None of this poop would be required if I were setting the JBossWSAdapter as the JAXBHandler for the request only via the InvocationContext (or some other request scope object). Unless of course (I just thought of this), the CommonMessageContext only has a copy of the Endpoint, in which case we're OK and I don't need to worry about any of the above issue. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4058380#4058380 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4058380

18 years, 9 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: WARNING: Deployer changes

by adrian＠jboss.org

I'll describe the changes in more detail later this week. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4058379#4058379 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4058379

18 years, 9 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 June 2007