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

[Design of JBoss jBPM] - Re: iCalendar wrapper

by kukeltje

anonymous wrote : Building in those channels into jBPM doesn't mean that you *must* use them Providing options to use them is still different to 'building in'. Just like the ESB did not build there flow engine themselves but use something externally developed library. anonymous wrote : Having such addons out of the box is a big deal (literally:-) Hmmmm... I do like DRY, but in this case I do want to.... having these additions out of the box does not mean we have to develop them ourselves.... That would be another DRY View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4138266#4138266 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4138266

18 years

1
0
0 / 0

[Design of JBoss Portal] - Re: common.text package update

by julien＠jboss.com

It is thread safe, the fields of the class are accessed in write operations in the class constructor. In the decode operations the fields are read only. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4138263#4138263 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4138263

18 years

1
0
0 / 0

[Design of JBoss Portal] - Re: Inter portlet communication between two portlets in diff

by Antoine_h

Wrong forum this kind of question should be in the user forum. and there are yet many answers about this question in this forum. see : http://jboss.org/index.html?module=bb&op=viewforum&f=215 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4138247#4138247 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4138247

18 years

1
0
0 / 0

[Design of JBoss Portal] - Re: common.text package update

by Antoine_h

Hello, I looked at the FastURLDecoder and the way it is used in the JSF backing beans, such as : org.jboss.portal.core.identity.ui.EditProfileAction Main question : FastURLDecoder is not multi thread safe ? then, in the EditProfileAction, it is used like that : private final static FastURLDecoder decoder = FastURLDecoder.getUTF8Instance(); and getUTF8Instance returns the same static instance of FastURLDecoder. then, in case two threads call the encode() method at the same time... there will be some mixing in the data, and bad result. no ? I am not very used to these multi thread safe issues, but it seems to me that : - either the FastURLDecoder should be programmed to be threads safe - either it should not be used as a static in a jsf backing bean did I missed something ? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4138244#4138244 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4138244

18 years

1
0
0 / 0

[Design of EJB 3.0] - Re: @SecurityDomain changes from AS42 to AS5

by alessio.soldano＠jboss.com

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

18 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: WARNING: Preparing release of MC betas

by adrian＠jboss.org

This looks ready to go to me. I'll move the open issues to the next beta release, none are very important for this beta. I've still got to do a standup test against jboss-head, but I did an early one yesterday and it shouldn't have changed much since then? There's one regression in the deployers tests, but that looks like an aop issue http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4138215#4138215 and since jboss-head has already been upgraded to this aop 2.0.0.CR8 release it shouldn't hold up our release. The deployers are actually doing what they are supposed to do for this test. So I'll go get a few hours sleep which will give you guys chance to see if there are other problems I haven't seen (and break it all again :-). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4138235#4138235 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4138235

18 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Field injection

by adrian＠jboss.org

I've fixed the security hole problems in the private field access, although I haven't tested every use case. I rewrote (deleted one) your tests since they were broken/making incorrect assumptions about how it should work. The one I deleted I tried to fix but it was like playing a game of "kaplunk" ;-) See the FieldsAccessControlTestCase in the controller tests for how to write it properly. It basically deploys two files (one during bootstrap which isn't subject to security and one manually that is). Implementation and a WARNING: The access to private fields is now correctly controlled inside the ReflectFieldInfoImpl with final methods that nobody can override. The only way the MC can get it wrong is by accessing fields when it is not using the controller context's AccessControlContext. i.e. it is running under its own privileges instead of whoever tried to register the bean. So the other use cases still need testing to make sure this does not happen (either now or in the future). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4138234#4138234 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4138234

18 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: testNotAnEar

by adrian＠jboss.org

"scott.stark(a)jboss.org" wrote : It looks like empty directories are not being copied over to target/test-classes: | Thanks, same behaviour as ant then :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4138228#4138228 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4138228

18 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: testNotAnEar

by scott.stark＠jboss.org

It looks like empty directories are not being copied over to target/test-classes: | [starksm@valkyrie deployers-vfs]$ ls target/tests-classes/structure/ear/ | archive.ear* noappxml.ear/ someappxml.ear/ | complexwithappxml.ear/ simplewithappxml.ear/ strict.ear/ | | ... | Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.031 sec <<< FAILURE! | testNotAnEAR(org.jboss.test.deployers.vfs.structure.ear.test.EARStructureRecognizeTestCase) Time elapsed: 0.016 sec <<< ERROR! | java.io.FileNotFoundException: File does not exist: C:\home\svn\JBossMC\jboss-deployers\trunk\deployers-vfs\target\tests-classes\structure\ear\notanear | If I just add an empty file to notanear, the mvn test output consistently passes: | [starksm@valkyrie deployers-vfs]$ touch src/resources/tests/structure/ear/notanear/empty | [starksm@valkyrie deployers-vfs]$ mvn test | ... | Results : | | Tests run: 155, Failures: 0, Errors: 0, Skipped: 0 | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4138223#4138223 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4138223

18 years

1
0
0 / 0

[Design of JBoss Build System] - Re: AS Components Bound to AS Release Cycle

by ALRubinger

Allright. I'm going to move the AS Components back to jboss-as-parent (out of jboss-as-component-matrix), and that'll have to suffice for now while I switch back to EJB3. A heads up that proper releases won't be possible until we tackle this. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4138222#4138222 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4138222

18 years

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 March 2008