Menu
▾
▴
jboss-dev-forums — The jboss development forum posts
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
(157) |
May
(789) |
Jun
(608) |
Jul
(554) |
Aug
(868) |
Sep
(654) |
Oct
(994) |
Nov
(803) |
Dec
(982) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
(1006) |
Feb
(1054) |
Mar
(1345) |
Apr
(1305) |
May
(1392) |
Jun
(1016) |
Jul
(265) |
Aug
(1) |
Sep
(8) |
Oct
(9) |
Nov
(8) |
Dec
(19) |
| 2007 |
Jan
(20) |
Feb
(10) |
Mar
(20) |
Apr
(8) |
May
(4) |
Jun
(1) |
Jul
(6) |
Aug
(3) |
Sep
(6) |
Oct
(12) |
Nov
(7) |
Dec
(13) |
| 2008 |
Jan
(5) |
Feb
(4) |
Mar
(34) |
Apr
(32) |
May
(22) |
Jun
(21) |
Jul
(30) |
Aug
(18) |
Sep
(30) |
Oct
(23) |
Nov
(86) |
Dec
(51) |
| 2009 |
Jan
(25) |
Feb
(26) |
Mar
(34) |
Apr
(47) |
May
(38) |
Jun
(25) |
Jul
(36) |
Aug
(9) |
Sep
(8) |
Oct
(10) |
Nov
(4) |
Dec
(17) |
| 2010 |
Jan
(7) |
Feb
(9) |
Mar
(26) |
Apr
(49) |
May
(52) |
Jun
(48) |
Jul
(39) |
Aug
(27) |
Sep
(9) |
Oct
(14) |
Nov
(7) |
Dec
(10) |
| 2011 |
Jan
(12) |
Feb
(9) |
Mar
(17) |
Apr
(33) |
May
(39) |
Jun
(36) |
Jul
(29) |
Aug
(26) |
Sep
(29) |
Oct
(38) |
Nov
(35) |
Dec
(27) |
| 2012 |
Jan
(20) |
Feb
(34) |
Mar
(29) |
Apr
(33) |
May
(45) |
Jun
(46) |
Jul
(50) |
Aug
(35) |
Sep
(55) |
Oct
(68) |
Nov
(79) |
Dec
(45) |
| 2013 |
Jan
(67) |
Feb
(20) |
Mar
(55) |
Apr
(52) |
May
(25) |
Jun
(25) |
Jul
(34) |
Aug
(27) |
Sep
(21) |
Oct
(21) |
Nov
(19) |
Dec
(12) |
| 2014 |
Jan
(10) |
Feb
(8) |
Mar
(13) |
Apr
(18) |
May
(36) |
Jun
(26) |
Jul
(17) |
Aug
(19) |
Sep
(13) |
Oct
(8) |
Nov
(7) |
Dec
(5) |
| 2015 |
Jan
(11) |
Feb
(2) |
Mar
(13) |
Apr
(15) |
May
(7) |
Jun
(2) |
Jul
(4) |
Aug
(3) |
Sep
(3) |
Oct
|
Nov
(2) |
Dec
(1) |
| 2016 |
Jan
(3) |
Feb
(5) |
Mar
(19) |
Apr
(34) |
May
(9) |
Jun
(10) |
Jul
(5) |
Aug
(10) |
Sep
(5) |
Oct
(11) |
Nov
(19) |
Dec
(7) |
| 2017 |
Jan
(4) |
Feb
(4) |
Mar
(8) |
Apr
(5) |
May
(12) |
Jun
(5) |
Jul
(11) |
Aug
(4) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <sco...@jb...> - 2006-06-29 20:07:04
|
For reference, the jaas definitions of the control flag:
anonymous wrote :
| 1) Required - The LoginModule is required to succeed.
| If it succeeds or fails, authentication still continues
| to proceed down the LoginModule list.
|
| 2) Requisite - The LoginModule is required to succeed.
| If it succeeds, authentication continues down the
| LoginModule list. If it fails,
| control immediately returns to the application
| (authentication does not proceed down the
| LoginModule list).
|
| 3) Sufficient - The LoginModule is not required to
| succeed. If it does succeed, control immediately
| returns to the application (authentication does not
| proceed down the LoginModule list).
| If it fails, authentication continues down the
| LoginModule list.
|
| 4) Optional - The LoginModule is not required to
| succeed. If it succeeds or fails,
| authentication still continues to proceed down the
| LoginModule list.
|
Those tests results look correct. We need to test with sufficient at the start:
| result = getResult("sufficient-permit-required-deny-policy");
| assertTrue("PERMIT?", AuthorizationContext.PERMIT == result);
| result = getResult("sufficient-permit-sufficient-deny-policy");
| assertTrue("PERMIT?", AuthorizationContext.PERMIT == result);
| result = getResult("optional-deny-sufficient-permit-required-deny-policy");
| assertTrue("PERMIT?", AuthorizationContext.PERMIT == result);
|
and that if nothing deterministically succeeds that we deny:
| result = getResult("sufficient-deny-optional-deny-policy");
| assertTrue("DENY?", AuthorizationContext.DENY == result);
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954501#3954501
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954501
|
|
From: <bst...@jb...> - 2006-06-29 20:02:06
|
Haven't checked, but I would assume because the HASingletonDeployer notifications mentioned in JBAS-2626 were only added in 4.0.4. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954500#3954500 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954500 |
|
From: osterday <do-...@jb...> - 2006-06-29 19:57:44
|
I thought it should only return the message IF you wanted other listeners to get the message. Maybe I'm thinking about this wrong - I'm still trying to grasp it all, but if the message is suppose to be returned back to the chain, what if the "to" doesn't exist in JBCS? I don't have nukes installed, so I don't really know about that listener/handler, but it looks like after you process the message to nukes, you don't want the chain to get the mail since the nukes address is for nukes. I'm wanting to use "real" JBCS email addresss to receive mails, but those mails that are from a certain address need to be processed (they contain xml) so our listener is first in the chain and decides if the mail should be put into our queue and handled by our process and return null if true so the message is NOT delivered to the JBCS user inbox. (I want to keep the configuration of this service easy for the end users so I don't want to create different email addresses.) I'm guessing a spam filter might work similarly if you want the message to be deleted for sure and not hit the users inbox. If I'm way off, let me know! Thanks! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954496#3954496 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954496 |
|
From: <go...@ic...> - 2006-06-29 19:20:51
|
I think the way the chain works, is that each mail listener in the chain, is supposed to return the message, so the next mail listener will have access to it...Imagine you could put your mail listener, after the JMSMailListener, then there would be no more mail listeners in chain to complain when message is null Though you probably already were aware of this... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954488#3954488 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954488 |
|
From: <ani...@jb...> - 2006-06-29 19:10:24
|
Scott, could you give a glance at the following combination of module behavior and assert that the results derived are correct.
| /**
| * Test the AuthorizationModules combination behavior
| */
| public void testCombinationBehavior() throws Exception
| {
| assertNotNull("PolicyConfig != null", policyConfig);
|
| int result = getResult("required-deny-sufficient-permit-policy");
| assertTrue("DENY?", AuthorizationContext.DENY == result);
|
| result = getResult("required-permit-sufficient-deny-policy");
| assertTrue("PERMIT?", AuthorizationContext.PERMIT == result);
|
| result = getResult("required-permit-required-deny-policy");
| assertTrue("DENY?", AuthorizationContext.DENY == result);
|
| result = getResult("required-permit-required-permit-policy");
| assertTrue("PERMIT?", AuthorizationContext.PERMIT == result);
|
| result = getResult("required-permit-required-permit-sufficient-deny-policy");
| assertTrue("PERMIT?", AuthorizationContext.PERMIT == result);
|
| result = getResult("required-permit-required-permit-requisite-deny-policy");
| assertTrue("PERMIT?", AuthorizationContext.PERMIT == result);
|
| result = getResult("required-permit-required-permit-optional-deny-policy");
| assertTrue("PERMIT?", AuthorizationContext.PERMIT == result)
|
| result = getResult("required-permit-required-deny-requisite-permit-policy");
| assertTrue("DENY?", AuthorizationContext.DENY == result);
|
| result = getResult("requisite-permit-requisite-permit-sufficient-deny-policy");
| assertTrue("PERMIT?", AuthorizationContext.PERMIT == result);
| }
|
The combination of the module control flag can be derived from the name.
For example:
| <jbsx:application-policy name="requisite-permit-requisite-permit-sufficient-deny-policy">
| <jbsx:authorization>
| <jbsx:policy-module code="org.jboss.security.authorization.modules.AllPermitAuthorizationModule" flag="requisite" />
| <jbsx:policy-module code="org.jboss.security.authorization.modules.AllPermitAuthorizationModule" flag="requisite" />
| <jbsx:policy-module code="org.jboss.security.authorization.modules.AllDenyAuthorizationModule" flag="sufficient" />
| </jbsx:authorization>
| </jbsx:application-policy>
|
Here two modules (requisite) permit and one module(sufficient) denies. The overall decision should be PERMIT.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954485#3954485
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954485
|
|
From: <tom...@jb...> - 2006-06-29 18:55:49
|
please check again. finally today i got to fixing things. it should be ok. if it is not yet resolved, please, ping me again. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954484#3954484 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954484 |
|
From: osterday <do-...@jb...> - 2006-06-29 18:48:44
|
I'm working on a mail listener. Using the ones provided, it been pretty easy to create one that's dynamically added and removed from the chain when our app is deployed/removed - really great work guys! But the issue is whether or not the listener should return null or not if it consumes the whole message. Right now I get an error message from the JMS listener (which is second in the chain) since it doesn't check if the message is null. (This is on M5.) Also, the MailListJMSListener has this code, so maybe nobody knows! // TODO: return null, or WrappedMail with empty to array? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954482#3954482 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954482 |
|
From: <sco...@jb...> - 2006-06-29 18:11:11
|
Ok, it does not look like this should require a new mc release to be able to augment the BeanSchemaBinding to support this. I'm thinking its just an extended SchemaBinding that has a wrapper root object to combine the mc metadata and adds another namespace and ObjectFactory for the jmx-depends list so as not to introduce non-mc metadata into the BeanSchemaBinding. http://jira.jboss.com/jira/browse/JBAS-3353 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954475#3954475 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954475 |
|
From: kukeltje <do-...@jb...> - 2006-06-29 17:27:30
|
I could reproduce it in another tree in a different workspace (yes stupid me) but this three was clean. On my other three there was an old version of a jbpm build library on the classpath. In the latest release (1.2) of JbpmExpressionEvaluator the getVariableResolver() is just gone. It is in 1.1. Same is true for evaluate(String, ExecutionContext) and getGroupNamesByUserAndGroupType. There is definately something wrong in CVS. Ronald View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954463#3954463 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954463 |
|
From: <cle...@jb...> - 2006-06-29 17:04:47
|
Or if you need to synchronize two HashMaps, maybe manually add partitions to MetaData. This is definelly a contention point. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954455#3954455 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954455 |
|
From: <mic...@jb...> - 2006-06-29 16:55:56
|
I cannot seem to be able to drive the CPU load to >85% in my Seam application stress testing. If I increase the client threads, the response time would simply increase and the CPU stays at around 85%. So, I did a thread dump, and found most HTTP threads are waiting at line 161 of class org.jboss.aop.metadata.MethodMetaData. This line is a synchronized access to a HashMap, and it is appreantly a contention point where multiple CPUs have to wait on each other.
| public class MethodMetaData implements MetaDataResolver {
|
| public synchronized Object getMethodMetaData(Method method, Object tag, Object attr) {
|
| // This is line 161:
| SimpleMetaData methodData = (SimpleMetaData)methodMetaData.get(method.toString());
|
| }
| }
|
Clebert suggested to use a concurrent HashMap instead of the method level synchronization here. What do you guys think?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954445#3954445
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954445
|
|
From: <kab...@jb...> - 2006-06-29 16:27:10
|
I have got the main AOP tests working with a security manager now. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954434#3954434 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954434 |
|
From: <man...@jb...> - 2006-06-29 16:11:41
|
Look at Interceptor.getInvocationContext().getTransaction() View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954427#3954427 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954427 |
|
From: <man...@jb...> - 2006-06-29 16:10:07
|
I'd say if it works on 1.4.0 then put it to HEAD. HEAD is the less-critical 2.0.0 tree anyway. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954424#3954424 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954424 |
|
From: <man...@jb...> - 2006-06-29 16:07:43
|
It is an interesting thought. Implementing it could be easy enough, using a JAAS-style provider and adding an interceptor to test the credentials of every call made. How would credentials be passed in though? Explicitly? On retrieving a Node? Or per call? Or something attached to the current thread? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954423#3954423 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954423 |
|
From: <cle...@jb...> - 2006-06-29 16:07:09
|
I will be releasing it next week or so. This should be resolved then. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954422#3954422 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954422 |
|
From: <man...@jb...> - 2006-06-29 16:05:28
|
Interesting. Do I detect a need to be able to define Fqns as 'global', so these are always replicated everywhere? Very,very kludgy... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954421#3954421 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954421 |
|
From: <cle...@jb...> - 2006-06-29 16:03:34
|
You need to recompile it. If you could send me the compilation scripts, I will add it to CVS. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954419#3954419 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954419 |
|
From: <mar...@jb...> - 2006-06-29 15:34:34
|
The technical ones are part of the JBoss World Vegas presentation given the previous week. Those are on the JBW web site. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954409#3954409 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954409 |
|
From: dbarron3 <do-...@jb...> - 2006-06-29 14:57:56
|
Agreed, the sound quality leaves something to be desired. Are the slides available separately for download? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954403#3954403 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954403 |
|
From: <sco...@jb...> - 2006-06-29 14:43:09
|
Right, see the org.jboss.management.j2ee.LocalJBossServerDomain jsr77 implementation in the jboss-x/management module which illustrates a service registering to receive lifecycle notifications. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954396#3954396 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954396 |
|
From: <dim...@jb...> - 2006-06-29 14:38:27
|
You don't really care who receives the notification, that's the whole point: anyone can subscribe to it. One example might be the management layer that creates its jsr77 view based on notifications received by other mbeans. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954393#3954393 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954393 |
|
From: <sco...@jb...> - 2006-06-29 14:38:18
|
The existence of the rar in/not in the deploy directory is a separate issue that relates to how the hot deployment service has to behave in the presence of a profile service that dictates what deployments are part of a server configuration. Certainly a rar can have jboss specific deployment descriptors. A deployer will ultimately have to support an external metadata configuration based on the management view it exposes to effectively integrate with the profile service though, because the profile service is not going to be writing out deployer specific descriptors. It will have an object representation it stores however, and this will be passed in as additional metadata at deployment time. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954392#3954392 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954392 |
|
From: ddegroff <do-...@jb...> - 2006-06-29 14:34:11
|
Absolutely brilliant, Tom! Your solution provides an excellent framework from which to build. I will pursue moving toward delivering the output I've constructed here: http://www.ehealthconnect.net/ehc/test270.xml For further thought/discussion, I should make mention of some ancillary issues (not at all requisite for pressing forward with straight transformation): 1. Validation (use of X12n implementation guides to determine correctness of both structure and content of entire EDI message). I can pretty much take ownership of this tedious issue, unless someone has extensive experience/expertise in this. 2. Looping. I will provide later further explanation of this issue. Suffice it to say at this point that there is a concept I refer to as "behavior of data", that has certain constructs repeating some number of times (see issue #1). 3. Reusable Objects. Quite a number of elements found within EDI are actually context-appropriate reuse of "standard" structures (name, address, etc.) This issue will become apparent when I publish the schema for the 270 output XML. Thanks again, Tom. Dave De View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954391#3954391 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954391 |
|
From: <ad...@jb...> - 2006-06-29 14:33:12
|
The deployer creates the DeploymentInfo (and classloader) like the old rar deployer, Except now the rar metadata is from ra.xml and the xxx-rar.xml overrides. There is just an additional source of metadata from the xxx-ra.xml it would also be that one that is watched for hotdeployment purposes. I'm not saying you should do it this way. It is one possible way to achieve the externalization of the overrides. Another would be an even more generic deployer that has something like: | <deploy> | <file>xxx.Xar</file> | <alt-dd-file>/some/location</alt-dd-file> | or | <alt-dd> | <!--inline stuff--> | </alt-dd> | </deploy> | But that has problems with the current way we use extensions to derive the deployment ordering. Again not an insurmountable problem. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954389#3954389 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954389 |
1965 messages has been excluded from this view by a project administrator.
