September 2007 - jboss-dev-forums

[Design of POJO Server] - Re: ManagedOperation aspects for the ProfileService.Manageme

by alesj

"scott.stark(a)jboss.org" wrote : | It has to tie into the setValue call for ViewUse.RUNTIME properties. However that is best done. Seems like within the ManagementViewImpl to the KernelBus is how it has to be done. Don't we need the KernelBus updates to replace the RuntimeComponentDispatcher? | The RuntimeComponentDispatcher will stay, it's the KernelBus that has changed. And by that our RuntimeComponentDispatcher impl has changed as well. I agree it should go into MVImpl, but what if we are deep into MC impl - which should be PS unaware? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4088628#4088628 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4088628

17 years, 3 months

1
0
0 / 0

[Design of POJO Server] - Re: ManagedOperation aspects for the ProfileService.Manageme

by alesj

"scott.stark(a)jboss.org" wrote : | The call to the ctxProp.setValue is the server side invocation on the ManagedProperty that is wired to the metadata. This changes the metadata instance associated with the deployment. | Changes metadata instance? How, where? But there is no actual runtime component invocation at the moment, right? "scott.stark(a)jboss.org" wrote : | This is what Weston is working on. | Weston, what's the status/progress of this? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4088627#4088627 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4088627

17 years, 3 months

1
0
0 / 0

[Design of POJO Server] - Re: ManagedOperation aspects for the ProfileService.Manageme

by scott.stark＠jboss.org

"alesj" wrote : | "scott.stark(a)jboss.org" wrote : | | ... we also need to send the change to the runtime component. | | | | How should we wire this with ManagementView? | Or just use plain KernelBus on the MC side? | It has to tie into the setValue call for ViewUse.RUNTIME properties. However that is best done. Seems like within the ManagementViewImpl to the KernelBus is how it has to be done. Don't we need the KernelBus updates to replace the RuntimeComponentDispatcher? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4088626#4088626 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4088626

17 years, 3 months

1
0
0 / 0

[Design of POJO Server] - Re: ManagedOperation aspects for the ProfileService.Manageme

by scott.stark＠jboss.org

"alesj" wrote : | I'm failing to see where this change gets applied on the server side? | ManagementView.process calls MainDeployer.process, which only processes undeployments and new deployments. | But I can't see where changed/updated components/deployments are processed ... | The call to the ctxProp.setValue is the server side invocation on the ManagedProperty that is wired to the metadata. This changes the metadata instance associated with the deployment. "alesj" wrote : | Was this fixed? | | | *** CONTEXTS IN ERROR: Name -> Error | | | | vfsfile:/C:/projects/jboss5/trunk/build/output/jboss-5.0.0.Beta3/server/profileservice/deploy/testHqldbDS-ds.xml -> org.xml.sax.SAXParseException: Premature end of file. | | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4088623#4088623 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4088623

17 years, 3 months

1
0
0 / 0

[Design of JBoss Admin Console] - Re: JBoss Application Server 4.2.1

by PeterJ

Issues are maintained in JIRA: http://jira.jboss.com/jira/browse/JBAS View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4088589#4088589 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4088589

17 years, 3 months

1
0
0 / 0

[Design of JBoss Admin Console] - JBoss Application Server 4.2.1

by kavipriyag

Is there are any documents or links available for the issues available in JBoss Application Server 4.2.1? Any documents or links available for the open issues that will be fixed in the future versions? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4088584#4088584 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4088584

17 years, 3 months

1
0
0 / 0

[Design of Security on JBoss] - Security Cache Flush on Http Session Expiration

by anil.saldhana＠jboss.com

| (10:09:25 AM) anil_msn: hello Remy. When the session expires, the session listener basically gets a tomcat session facade (that implements httpsession). I was interested in the principal being stored as a note in catalina session. I doubt we will be able to get to the actual catalina session from the facade | (10:10:31 AM) Remy Maucherat: the facade strictly implements the javax API, and thus does not add any custom call to internal structures; the principal can be accessed through other objects (the request, I think) | (10:11:26 AM) Remy Maucherat: so can you use the request instead ? | (10:11:34 AM) anil_msn: for a regular session.invalidation, we are in a path of request. But when the container expires sessions after an hour or so, there is no request | (10:11:46 AM) anil_msn: we are using the request approach for active sessions getting invalidated | (10:12:20 AM) anil_msn: only the case of container expiring sessions | (10:12:51 AM) anil_msn: I think any approach we take will be like a hack | (10:13:13 AM) anil_msn: better ignore the use case (some customer asked for it) | (10:16:32 AM) Remy Maucherat: hum, right, that's interesting stuff, but it's not going to work | (10:17:16 AM) anil_msn: I was thinking about placing the principal after authentication into the http session. But are u saying that the facade will lose it? | (10:17:25 AM) anil_msn: anyway we are not doing the hack | (10:19:33 AM) Remy Maucherat: no, you can put an object in the session as an attribute | (10:20:10 AM) anil_msn: I cannot justify placing the principal in the session attribute map, just to solve one rare use case. | (10:20:22 AM) anil_msn: we recommend session invalidation anyway as a best practice. | (10:23:05 AM) Remy Maucherat: of course, but most likely they can use a filter or listener to do it | (10:24:53 AM) anil_msn: That is a good suggestion. We can provide an ondemand valve to place the principal on the session (only if the customer wants it) and then update our session listener to also look for this principal | (10:25:14 AM) anil_msn: if the customer is so bent on this use case, he can configure this valve that we will provide | (10:27:22 AM) Remy Maucherat: it would be better to use a filter: his application will always need the attribute to run | We can solve it this way (based on a suggestion from Remy): a) We will provide a servlet filter in "org.jboss.web.tomcat.security" called as PrincipalSessionAttributeFilter. This filter has one objective - place the principal from request.getUserPrincipal in the session attribute (if not already present) under a key like JBOSS_PRINCIPAL. This filter should be configured by the user on an on-demand basis. We will not enable this filter by default. (If the customer wants this to be applied to all web apps, he can configure this in web.xml of the jboss tomcat service). b) Update our session binding listener to also look for this JBOSS_PRINCIPAL in the session attribute to flush. Issue: When sessions expire on their own, we do not have any principal handy for the session because we do not have any requests coming in (to be able to pick it up from SecurityAssociation). Hence we need a way to pick the principal off of the session maybe. The Tomcat session does retain the principal in its session. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4088485#4088485 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4088485

17 years, 3 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: Endpoint redeployment

by richard_opalka

To be more concrete problem is related to JAXWS endpoints only. In the case of JAX-RPC endpoints there's no problem, because webservices archive detections is based on webservices.xml file existence in classloader. Richard View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4088477#4088477 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4088477

17 years, 3 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: Endpoint redeployment

by richard_opalka

"thomas.diesler(a)jboss.com" wrote : Richard, you are probably aware that JBWS124TestCase already works for all jbossas versions, aren't you? In this case it works because JAXRPC war deployer hook checks whether there's the webservices.xml file. If yes it is recognized as webservices archive. In the case of JAX-RPC based webservices that provide webservices.xml there's no problem. In such case webservices.xml is inspected to look for webservices, and not web.xml (as in the case of JAXWS services) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4088471#4088471 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4088471

17 years, 3 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: Endpoint redeployment

by thomas.diesler＠jboss.com

Yes anonymous wrote : | An endpoint deployment must survive a server crash. When the server comes up again, endpoints must be recognized as such. | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4088468#4088468 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4088468

17 years, 3 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums September 2007