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

[Design the new POJO MicroContainer] - Initial OSGi code + small MC fixes

by alesj

I've added all my existing OSGi code into MC trunk (work in progress). There are no tests yet. We should get (at least) two types of tests there: - MC features tests (my todo) - OSGi testsuite (Adrian or Kevin) -- Equinox is RI for spec v4.1 --> 'TCK' tests -- Felix testsuite; probably RichardH can provide some help I've also added few MC changes - mostly repackaging and new interface/classes introduction. Since Maven builds/tests are non-operational (at least for me) I'm not able to test this changes (but I believe/hope they don't have any impact on tests). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4033643#4033643 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4033643

17 years, 11 months

1
0
0 / 0

[Design of JBoss Portal] - Re: logout from my portal instance

by psalvadori

Hi Julien first of all thanks for your quick response. I tried what you said but nothing better. I didn't understand who intercept the signout request. I suppose that there must be a servlet that do it or something similar but I didn't find it in the source code. I made an attempt to resolve my problem but I didn't receive any results. I tried to extend the class PageCustomizerInterceptor, the one that insert the logout html code in every logged pages. In my implementation, in the method "injectDashboardNav", I inserted the following code: | | SignOutCommand cmd = new SignOutCommand("portal/GFPortal/default"); | URLContext urlContext = controllerCtx.getServerInvocation().getServerContext().getURLContext(); | String logoutURL = controllerCtx.renderURL(cmd, urlContext.asNonAuthenticated(), null); instead of the original code: | SignOutCommand cmd = new SignOutCommand(); | URLContext urlContext = controllerCtx.getServerInvocation().getServerContext().getURLContext(); | String logoutURL = controllerCtx.renderURL(cmd, urlContext.asNonAuthenticated(), null); the string "portal/GFPortal/default" is the page where I want to redirect when I signout. But even in this case nothing happens. I hope You can help me because it is very urgent for me. Thanks in advance, Paolo. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4033641#4033641 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4033641

17 years, 11 months

1
0
0 / 0

[Design of JBossXB] - Re: Cleaning up the jbossxb projects

by alex.loubyansky＠jboss.com

branch/1_0 appears to be not a copy of the 1.0.0.CR9 tag but the trunk? Author: scott.stark(a)jboss.org | Date: 2007-03-07 19:05:37 -0500 (Wed, 07 Mar 2007) | New Revision: 2285 | | Added: | jbossxb/branches/1_0/ | Log: | Make a 1.0 branch from the 1.0.0.CR9 release | | Copied: jbossxb/branches/1_0 (from rev 2284, jbossxb/trunk/src) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4033640#4033640 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4033640

17 years, 11 months

1
0
0 / 0

[Design of JBoss internal QA (Test Suite)] - Re: Updating the server task to detect OutOfMemoryErrors

by mvecera＠redhat.com

I don't know how to put the JUnitMemCheckTestRunner under the org.jboss.... package, becouse there are several other JUnit source files that must be modified in order to use the new test runner instead of the old one. Should I rewrite them and put them in the new package as well? If so, wasn't it be easier to copy the original JUnit ant task sources to the org.jboss.... and rewrite them directly instead of extending JUnitTestRunner? It is not possible to move only the modified sources to org.jboss.... package because of package visibility dependencies. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4033636#4033636 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4033636

17 years, 11 months

1
0
0 / 0

[Design of OSGi Integration] - Services/Components XML support

by alesj

Regarding this JIRA issue: http://jira.jboss.com/jira/browse/JBOSGI-11 I already have a JBossXB support for the schema Spring and OSGi alliance came up with. But I think that we could only support 'Declarative Services Specification', all other fancy stuff can be done through MC beans. I'll rewrite my initial stuff to handle DSS. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4033620#4033620 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4033620

17 years, 11 months

1
0
0 / 0

[Other JBoss Development Design] - Re: possible bug in run.sh on Solaris

by dimitris＠jboss.org

Can you please open a JIRA bug report? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4033609#4033609 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4033609

17 years, 11 months

1
0
0 / 0

[Other JBoss Development Design] - possible bug in run.sh on Solaris

by quentena

We've been using jboss 4.0.5.GA and we think we've found a bug with run.sh on Solaris (9 or 10). This link is the patch that seems to have introduced this problem: http://jira.jboss.com/jira/browse/JBAS-3748 This link is where the patch was discussed: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=92156 To trigger the bug, you need to set LAUNCH_JBOSS_IN_BACKGROUND. Then start the jboss server normally. Once it's started stop the server. The JVM stops, however the run.sh script hangs around consuming 100% of a single CPUs resources. The problem seems to be this bit of script, plus the fact that the script shebang is #!/bin/sh | while [ "$WAIT_STATUS" -ne 127 ]; do | JBOSS_STATUS=$WAIT_STATUS | wait $JBOSS_PID 2>/dev/null | WAIT_STATUS=$? | done | On Solaris, #!/bin/sh is *real* bourne shell and the wait shell built-in for /bin/sh on Solaris returns 0 (not 127) if the PID (passed as an argument) doesn't exist. The man page for wait states that this is the correct behaviour. Anyway, wait returns 0 and the while loop continues for ever burning up CPU resources (until you kill it with one of the signals not being trapped). We've thought of two possible fixes for this: 1) change the shebang to be #!/bin/bash. This works OK on Linux & Solaris (provided you've installed bash) but I can't speak for other OS's. 2) test and alias wait to the program version if it exists. Something like this near the top of the script: | if [ -x /bin/wait ]; then | alias wait='/bin/wait' | fi | Has anyone else run across this problem? Can anyone think of a better solution? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4033567#4033567 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4033567

17 years, 11 months

1
0
0 / 0

[Design of POJO Server] - Re: fixing some mem leaks?

by scott.stark＠jboss.org

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

17 years, 11 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Migration to maven

by Kevin.Conner＠jboss.com

"pgier" wrote : I think that dependency is currently being picked up through kernel. | deployers -> kernel -> dependency. | Did the build fail for you? I tried a clean checkout, and it seems ok for me. Okay, the reason it is failing in my build is two fold - I am using maven 2.0.5 instead of 2.0.4 (this appears to build under 2.0.4) - there is a second transitive specification of jboss-dependency The second dependency is coming from deployers->jboss-aop->jboss-dependency(2.0.0.Beta) It is this 2.0.0.Beta version which is being picked up by the 2.0.5 compile stage, hence the failure. I'm not yet sure why 2.0.4 and 2.0.5 resolve their dependencies in a different way but I will investigate further tomorrow. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4033559#4033559 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4033559

17 years, 11 months

1
0
0 / 0

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

by tom.elrod＠jboss.com

Based on recent conversations, seems like there is enough interest in remoting 3 to start working on it in earnest. The biggest reason for remoting 3 is the fundamental change from being RPC based to being async message based (i.e. NIO). So I wanted to start a discussion thread about requirements and thoughts on design (and even implementation in some cases). For a starting point, would like to use the 'Transport layered model' and 'NIO' sections from http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossMessagingRemotingAPIExtensi.... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4033558#4033558 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4033558

17 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 April 2007