[Design of JBoss Web Services] - Removing JACC Permissions Hack
by richard.opalka@jboss.com
This is related to: JBAS-5935
I'm trying to remove JACC permissions hack in JBossWS AS integration code base and I have two issues with that:
ad1) When I'll comment out WSJACCPermissionsDeploymentAspect DA from
jboss-5.2.0.Beta/server/all/deployers/jbossws.deployer/META-INF/stack-agnostic-jboss-beans.xml and I'll start AS:
[/home/opalka][/opt/svn/jbossas/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/bin]>./run.sh -c all
and finally I'll run the test
[/home/opalka][/opt/svn/jbossas/branches/Branch_5_x/testsuite]>./build.sh one-test -Dtest=org.jboss.test.webservice.jbws309.JBWS309TestCase
I'd expect this test to fail, but it isn't. What is going on wrong with it? In that usecase JACC permissions shouln't be generated at all and test should fail, at least from what I read in associated JIRA JBAS-4644
ad2) I don't know how to fix that issue properly? Can I move WarSecurityDeployer from POST_CLASSLOADER deployers map to REAL_CLASSLOADERS map, or it have to stay in POST_CLASSLOADER map to prevent potential security attacks?
Associated JBossWS deployers that generate web meta data cannot be moved from REAL to POST_CLASSLOADER stage because of dependency on EJB3 REAL deployers.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4250574#4250574
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4250574
16 years, 7 months
[Design of Embedded JBoss] - Do we need Asset.getPath?
by ALRubinger
Have had some debates with both Aslak and John on the subject. From IRC today:
"#jboss-dev" wrote : ALR: ping
| baileyje: Pong
| ALR: So I had thrown together a MemoryMap impl earlier before I realized Aslak had already put a partial one up.. Whoops
| baileyje: Hehe, whoever gets there first in working form wins.
| ALR: he ran into the same issue I did. Asset does not have enough data to really support the Archive.add(Asset...) functionality.
| baileyje: Yep.
| ALR: Is that encompassed in another task, or should there be an new task to update the API to support getting Path like info from an asset?
| baileyje: This is something we'd debated a lot.
| baileyje: I think I left it to aslak to determine if we need some getPath from Asset or not. Hoping we wouldn't need it.
| ALR: Yeah. Seems like you could get rid of it if required a Path of every addition
| baileyje: It may be demanded by TMPARCH-6
| baileyje: Right.
| I think my proposal was that every Asset addition needed a path
| And that "container " additions could know how to supply it.
| ALR: That would keep Asset cleaner
| Like: addManifest("String") would assemble the default Path and Asset to add, then delegate to add(Path,Asset)
| baileyje: Yes, but I'm not sure if it works for every case. I like the cleaner approach too.
| aslak disagreed on that poing.
| *point
| ALR: Yeah..
| ALR: He wants the default path as a required attribute on each asset?
| baileyje: Yes.
| ALR: hmmm..
| baileyje: I'll review your patches in a bit. Trying to keep up with you guys while I'm pulled away to other things this week.
| ALR: seems like we should require the path and leave asset clean and rely on the containers to establish the paths, until we have compelling evidence the Asset needs a path attr..
| baileyje: That's my position.
| baileyje: If you have the time to prove that to aslak, awesome.
| ALR: K. I will see if I can put something together.. It makes the MemoryMap much easier to impl a path required..
| And if in trying to prove it he was right all along, we eat our words.
| I'll mail him this little discussion
| for sure..
| Or better, post on the forum.
Aslak, now public for your review at your convenience.
Also I'd like to do more forum posts for topics that should leave some trail. So we can all be in the conversation and remember the history.
S,
ALR
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4250485#4250485
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4250485
16 years, 7 months