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

[Design of POJO Server] - Re: Exploded WAR archive with no web.xml is no longer suppor

by adrian＠jboss.org

"adrian(a)jboss.org" wrote : | my.war/ | my.war/WEB-INF/class/MyServlet.class | I assume the servlet is annotated. ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181532#4181532 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181532

17 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: Exploded WAR archive with no web.xml is no longer suppor

by adrian＠jboss.org

It should be done in the WarStructureDeployer. Otherwise a war that looks like this: my.war/ my.war/WEB-INF/class/MyServlet.class wouldn't have the correct classpath, etc. i.e. we treat anything that ends with a .war as a war regardless even if it doesn't contain a WEB-INF/web.xml View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181531#4181531 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181531

17 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: new QueueBrowser implementation

by ataylor

anonymous wrote : My point was, that if you are on message 5, and message gets removed from the head which is the 99% case, then it shouldn't affect you. There is no need to go anywhere. If you remove a message from the head then next time you call next() on the iterator it will fail. you would then need to recreate the iterator and traverse back to the correct point. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181530#4181530 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181530

17 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: new QueueBrowser implementation

by timfox

"ataylor" wrote : anonymous wrote : In most cases, refs are only ever removed from the head of the queue, so you can just go back to the beginning of the queue. That's the 99% case and is pretty trivial. | | If you've iterated over 5 messages and then one is removed you don't go back to the beginning, you go to 4 which is the last message you looked at. | My point was, that if you are on message 5, and message gets removed from the head which is the 99% case, then it shouldn't affect you. There is no need to go anywhere. The only case that should affect the iterator is when the current node disappears in which case you can either iterate up from the beginning, or the queue can trap the delete all the call the iterator with the next node. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181519#4181519 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181519

17 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: Masking passwords in logs

by alesj

Leaving us with 1) and 3) - joining the two items. Perhaps there is no need to put this into commons, since it's really an implementation detail of AS. I would then put it somewhere in AS, making it as configurable as possible, and definitely used by all - single point of masking. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181518#4181518 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181518

17 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: Masking passwords in logs

by alesj

"alesj" wrote : | 2) it should be done generic | e.g. user might want to mask other attributes as well | | @MaskIt | public void setFoo(String foo) | As this masking is done in parse state, there is no way to get annotations, so this idea fails. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181516#4181516 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181516

17 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: Masking passwords in logs

by alesj

My initial post to Marcus: "alesj" wrote : | This is not the way to do it. ;-) | | 1) if eventually done is such non-generic way, there should be at least just one place to do it - e.g. MaskPasswordHelper in jboss-commons | | 2) it should be done generic | e.g. user might want to mask other attributes as well | | @MaskIt | public void setFoo(String foo) | | 3) there should be a set of default masking attributes | this set should be configurable | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181515#4181515 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181515

17 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: new QueueBrowser implementation

by ataylor

anonymous wrote : In most cases, refs are only ever removed from the head of the queue, so you can just go back to the beginning of the queue. That's the 99% case and is pretty trivial. If you've iterated over 5 messages and then one is removed you don't go back to the beginning, you go to 4 which is the last message you looked at. Also, if messages are being added/removed all the time, then the iterator would fail pretty much every time with a concurrentModificationException. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181514#4181514 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181514

17 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Masking passwords in logs

by mmoyses

I was given a task to mask passwords that appear in the logs, as it's a security flaw to expose such information. So far I have identified XSLSubDeployer, ServiceConfigurator and ServiceDeploymentDeployer as the classes that parse the information in the XMLs and eventually print a password in plain text in the log for debug purposes. I have committed a change to mask these passwords, but as Ales pointed, this is not a generic solution. I am opening this thread so we can discuss a better solution for this. Please contribute with your ideas. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181513#4181513 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181513

17 years, 6 months

1
0
0 / 0

[Design of JBoss Portal] - permission bug ?

by cpage

Hi, I noticed a strange behaviour in permissions. When i initialize a PortalObjectPermission (or an InstancePermission) with some actions, the "getActions()" function return different actions. For example : | PortalObjectPermission perm = new PortalObjectPermission(myPageId, "view"); | String actions = perm.getActions(); // --> return create,personalizerecursive,dashboardrecursive | | perm = new PortalObjectPermission(myPageId, "personalize"); | actions = perm.getActions(); // --> return personalizerecursive,dashboardrecursive | In getActions(), to have same actions, i replace int mask = 2 >> i; by : int mask = 1 << i; If it's not a bug, can you explain please ? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181510#4181510 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181510

17 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 October 2008