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

[Design the new POJO MicroContainer] - Re: Illegal tokens

by alesj

"scott.stark(a)jboss.org" wrote : I don't see that we are helping as '.*x' is a valid file name. We just need to handle the distinct names '.' and '..' as relative paths and anything else is just another name, however strange it might be. | OK, I'll disable it by default: | + /** Catch some suspicious tokens */ | + private static boolean errorOnSuspiciousTokens; | + | /** | * Utility class | */ | @@ -124,7 +127,13 @@ | else if (specialToken == CURRENT_PATH && bufferLength == 0) | specialToken = REVERSE_PATH; | else if (specialToken == REVERSE_PATH && bufferLength == 0) | - throw new IllegalArgumentException("Illegal token (" + specialToken + ch + ") in path: " + path); | + { | + if (errorOnSuspiciousTokens) | + throw new IllegalArgumentException("Illegal token (" + specialToken + ch + ") in path: " + path); | + | + buffer.append(specialToken).append(ch); | + specialToken = null; | + } | else | buffer.append(ch); | } | @@ -134,7 +143,7 @@ | if (specialToken != null) | { | // we don't allow tokens after '..' | - if (specialToken == REVERSE_PATH) | + if (errorOnSuspiciousTokens && specialToken == REVERSE_PATH) | throw new IllegalArgumentException("Illegal token (" + specialToken + ch + ") in path: " + path); | | // after '.' more path is legal == unix hidden directories | @@ -222,4 +231,14 @@ | { | return REVERSE_PATH == token; | } | + | + /** | + * Set errorOnSuspiciousTokens flag. | + * | + * @param errorOnSuspiciousTokens the errorOnSuspiciousTokens flag | + */ | + public static void setErrorOnSuspiciousTokens(boolean errorOnSuspiciousTokens) | + { | + PathTokenizer.errorOnSuspiciousTokens = errorOnSuspiciousTokens; | + } | But advanced user can still turn it on. e.g. initialize.xml in JBossAS View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4187756#4187756 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4187756

17 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Changes on the JBM stack on JBoss5

by vblagojevic＠jboss.com

Now that I think about it a bit more it would be better to make the tests that emulates server startup where all channels share underlying transport? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4187755#4187755 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4187755

17 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Changes on the JBM stack on JBoss5

by vblagojevic＠jboss.com

Ok, lets pursue this one until the root cause is found. I will test flush on my usual tests on 2.6 branch on a continuous loop until a failure like this one shows up. I will test two options one with connect and state transfer and the other where connect and state transfer are separate calls. Do you have a better game plan or a suggestion? Regards, Vladimir View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4187751#4187751 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4187751

17 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Changes on the JBM stack on JBoss5

by bstansberry＠jboss.com

"vblagojevic(a)jboss.com" wrote : ... I was confused when I saw that you are not using FLUSH in your stack, are you? FLUSH is used. See http://viewvc.jboss.org/cgi-bin/viewvc.cgi/messaging/branches/Branch_1_4/... anonymous wrote : Anyway, the root cause is that the cluster could not be flushed for whatever underlying reason that might have happened and therefore the state retrieval did not proceed. OK, but we need to figure out why this happens. I looked further at this one, and all that's going on is normal channel startup repeated many times over the course of a testsuite run; eventually one fails. Like you say, intermittent. My gut impression from observing various testsuite runs is flush issues happen on this kind of normal startup quite infrequently, but still too frequently. In this particular case, the testsuite started 3 nodes about 50 times (stopping all 3 after the start); the failure occurred on the 3rd node in the ~50th cycle. I think Clebert's suggestion on the forum of using some JBM test infrastructure to automate doing this over and over w/o wasting time running actual JBM tests is a good one. Do you have bandwidth to pursue such a task? [/url] View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4187749#4187749 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4187749

17 years, 5 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re:

by david.lloyd＠jboss.com

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

17 years, 5 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re:

by scott.stark＠jboss.org

I don't see that we are helping as '.*x' is a valid file name. We just need to handle the distinct names '.' and '..' as relative paths and anything else is just another name, however strange it might be. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4187742#4187742 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4187742

17 years, 5 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re:

by alesj

"david.lloyd(a)jboss.com" wrote : Is there a good reason to not allow this? Trying to help users? As I doubt someone intentionally puts '...' or '..somepath' (if this is not legal) into VirtualFile::findChild. At the beginning we didn't even allow '.' or '..', so when I was implementing that, I left some restrictions. If they don't make sense, I can easily remove them. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4187728#4187728 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4187728

17 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Changes on the JBM stack on JBoss5

by clebert.suconic＠jboss.com

anonymous wrote : I am not familiar with message ordering If you are saying that because of the latest testsuite that failed on Hudson, this error don't have anything to do with message-ordering. Last run it happened on the message ordering test, but it could happen on any clustered test on JBM. anonymous wrote : am not familiar with .... state semantics that have to be satisfied When we start JBM, we aways get the state from the cluster on the jbm-control channel. Look at GroupMember.start method (on the JBM tree): | public void start() throws Exception | { | this.controlChannel = jChannelFactory.createControlChannel(); | | this.dataChannel = jChannelFactory.createDataChannel(); | | // We don't want to receive local messages on any of the channels | controlChannel.setOpt(Channel.LOCAL, Boolean.FALSE); | | dataChannel.setOpt(Channel.LOCAL, Boolean.FALSE); | | MessageListener messageListener = new ControlMessageListener(); | | MembershipListener membershipListener = new ControlMembershipListener(); | | RequestHandler requestHandler = new ControlRequestHandler(); | | dispatcher = new MessageDispatcher(controlChannel, messageListener, membershipListener, requestHandler, true); | | Receiver dataReceiver = new DataReceiver(); | | dataChannel.setReceiver(dataReceiver); | | starting = true; | | controlChannel.connect(groupName + CONTROL_SUFFIX); | | if (!((JChannel)controlChannel).flushSupported()) | { | throw new IllegalStateException("Flush is not supported on the UDP Channel, please check your JGroups UDP stack as Flush is required"); | } | | //The first thing that happens after connect is a view change arrives | //Then the state will arrive (if we are not the first member) | //Then the control messages will start arriving. | //We can guarantee that messages won't arrive until after the state is set because we use | //the FLUSH protocol on the control channel | | boolean first = !(controlChannel.getState(null, stateTimeout)); | So, the semantic we expect is FLUSH aways returning the state from the cluster, right after the connect. Now something on the change presented at the first post on this thread changed this semantic causing the exception somehow. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4187727#4187727 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4187727

17 years, 5 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re:

by david.lloyd＠jboss.com

Any number of "." in any position in a path element should be valid IMO. Is there a good reason to not allow this? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4187726#4187726 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4187726

17 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: JBAS-5689, bootstrap deployments not seen by profileserv

by scott.stark＠jboss.org

It seems like we need an additional DeploymentState like EXTERNAL that flags a DeploymentUnit/DeploymentContext as not subject to the deploy/undeploy behavor of the MainDeployer. The problem with just ignoring DeploymentState.DEPLOYED deployments in addContext is that it will be undeployed when the MainDeployer is shutdown. Alternatively, the ManagedDeployment/ManagedObject stuff needs to be pulled out of the MainDeployer since we are interested in this information for deployments that are outside of the MainDeployer. Maybe the bootstrap ManagedDeployments can just be created separately without reference to the MainDeployer. I'll explore that more today as the current path is too invasive. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4187719#4187719 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4187719

17 years, 5 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 November 2008