September 2009 - jboss-dev-forums

[Embedded JBoss Development] - ShrinkWrap - Descriptors

by aslak

I played around with how we could impl descriptors into the archives last night.. Basicly; - a WebArchiveDescriptor IF with methods like addFilter, addServlet etc. - a JAXB based WebArchiveDescriptorAsset that handles the web.xml struct. - the WebContainer extends WebArchiveDescriptor - the WebArchiveDescriptorAsset is added to path WEB-INF/web.xml in the constructor of WebContainerBase. - WebContainerBase impls WebArchiveDescriptor as a 'double' delegate, delegate the servlet/filter/listener classes to the Archive and the configuration to the WebArchiveDescriptorAsset. Have look at the impl, http://shrinkwrap.pastebin.com/m37e1ccc6. A example usage testcase, http://shrinkwrap.pastebin.com/m19df310e. And the web.xml output: http://shrinkwrap.pastebin.com/m55b0fec3. What you think? (ps: and yes, I do realize that this is probably not a priority for v. 0.1 :o) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4257253#4257253 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4257253

16 years, 6 months

1
0
0 / 0

[JBoss Identity Development] - Re: AppliesTo support for STSClient (previously WSTrustClien

by beve

Hi Stefan, great, then I'll go ahead and add this :) When reading the WS-Trust spec I noticed that TokenType and AppliesTo are option but one of them 'SHOULD' be specified and this is also verified by the StandardRequestHandler. How about having the ability to specify both though, would this be a valid option for a client? One example is for the ESB where we have an action that can be configured with either a TokenType or an EndpointURI. We will need to check that one or the other has been specified and then call the appropriate method. But if there was a method like the following no checks would be needed and it would only be one method call: public Element issueToken(String endpointURI, String tokenType) throws WSTrustException | { | if (endpointURI == null && tokenType == null) | { | throw new WSTrustException("Either endpointURI or tokenType must be specified"); | } | RequestSecurityToken request = new RequestSecurityToken(); | setAppliesTo(endpointURI, request); | setTokenType(tokenType, request); | return issueToken(request); | } | What do you think, is it worth adding such a convenience method? Thanks, /Daniel View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4257251#4257251 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4257251

16 years, 6 months

1
0
0 / 0

[EJB Development] - Re: Entity bean deadlock

by bartatamas

I think it has the same problem. thread1 is in A.getTitle so locks A. thread2 is in B.getTitle so locks B. thread1 gets B and calls Sync.getName(B), and waits for B there (in b.getName() because thread2 locks B) thread2 gets A and waits for the Singleton to call getName(A), but thread1 will not return View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4257237#4257237 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4257237

16 years, 6 months

1
0
0 / 0

[JBoss Identity Development] - Re: AppliesTo support for STSClient (previously WSTrustClien

by sguilhen＠redhat.com

Hi Daniel, yes, I totally agree with you here. AppliesTo is an important bit of the WS-T spec and the STS supports it, so there is no reason at all for this to be missing in the client side. As a matter of fact, AppliesTo is a lot more important than specifying the token type, as it identifies the target endpoint and this allows the STS to perform very important work, like encrypting proof keys using the target's public key - something not possible when the target endpoint is unknown. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4257220#4257220 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4257220

16 years, 6 months

1
0
0 / 0

[JBoss Identity Development] - AppliesTo support for STSClient (previously WSTrustClient)

by beve

Hi guys, I noticed that there is server-side support for the AppliesTo element but I could not find this in the client. Is this intentional? For the STSClient you only have the ability to specify a tokenType and it might be nice to have both options? Perhaps there could be somethings like this: public Element issueTokenForEndpoint(final String endpointURI) throws WSTrustException | { | RequestSecurityToken request = new RequestSecurityToken(); | request.setAppliesTo(WSTrustUtil.createAppliesTo(endpointURI)); | return issueToken(request); | } What do you think? Can I add this? Thanks, /Daniel View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4257198#4257198 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4257198

16 years, 6 months

1
0
0 / 0

[EJB Development] - Re: Entity bean deadlock

by le_garcon_enerve

Maybe you could use A: getTitle() { return name + getSync().getName(getB()); } B: getTitle() { return name + getSync().getName(getA()); } Where Sync is a Singleton with Sync: syncronised getName(Bean b){ return b.getName(); } This way the threads run without interference until on of them calls the getName() of Sync. At this point, one of them is prone to win the race, and the syncronisation within Sync avoids the deadlock. The penalty for the indirect call to Sync should not be too bad if the three beans are in the same VM. Didn't try it, though ;-) Cheers , Georg View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4257123#4257123 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4257123

16 years, 6 months

1
0
0 / 0

[JBoss Messaging Development] - Re: Compatibility with JGroups 2.8

by bstansberry＠jboss.com

The HornetQ thread: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=161702 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4257084#4257084 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4257084

16 years, 6 months

1
0
0 / 0

[JBoss Portal Development] - Error after login into the admin module

by rashmi_ceru1

Hi , When i log into the admi side in the server log following error messages are displayed and it has made the complete admin module very slow . it takes around 10 mins to display one page in the admin and on whole it makes the application completely slow . can any help why this error is coming . 17:58:39,961 ERROR [PortalPermissionCollection] Permission check against the repository failed java.lang.IllegalArgumentException: Illegal action VIEW at org.jboss.portal.core.model.instance.InstancePermission.addAction(InstancePermission.java:158) at org.jboss.portal.core.model.instance.InstancePermission.(InstancePermission.java:107) at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl.createPermission(InstanceContainerImpl.java:179) at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl.getPermission(InstanceContainerImpl.java:511) at org.jboss.portal.core.model.instance.InstancePermission.implies(InstancePermission.java:176) at org.jboss.portal.security.PortalPermissionCollection.implies(PortalPermissionCollection.java:96) at org.jboss.portal.security.impl.jacc.Permissions.implies(Permissions.java:93) at org.jboss.portal.security.impl.jacc.SecurityContext.implies(SecurityContext.java:81) at org.jboss.portal.security.impl.jacc.JACCPortalAuthorizationManager.internalCheckPermission(JACCPortalAuthorizationManager.java:272) at org.jboss.portal.security.impl.jacc.JACCPortalAuthorizationManager.checkPermission(JACCPortalAuthorizationManager.java:301) at org.jboss.portal.security.impl.jacc.JACCPortalAuthorizationManager.checkPermission(JACCPortalAuthorizationManager.java:326) at org.jboss.portal.core.impl.model.instance.InstanceContainerImpl.org$jboss$portal$core$impl$model$instance$InstanceContainerImpl$getDefinitions$aop(InstanceContainerImpl.java:390) at View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4257083#4257083 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4257083

16 years, 6 months

1
0
0 / 0

[JBoss Messaging Development] - Re: Compatibility with JGroups 2.8

by bstansberry＠jboss.com

Ah, of course, new forum is why this forum suddenly went silent a month ago! I'll start a thread on the AS 6 conversion to hornetq there. Meanwhile, Tim, any thoughts you have on the current topic would be most appreciated. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4257078#4257078 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4257078

16 years, 6 months

1
0
0 / 0

[JBoss Messaging Development] - Re: Compatibility with JGroups 2.8

by timfox

No-one from AS team has, as yet, discussed timescales for upgrading AS to use HornetQ with me, but if you like, you can start a discussion on the HornetQ dev forum about this. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4257068#4257068 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4257068

16 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 September 2009