[JBoss Seam] - Re: UPDATED: SelectItems (the one with the EntityConverter)
by fonseca
Hello Peter,
I'm having a few troubles using your component, could you please help me out? I'm using the 1.1.1beta1 release, and my problem arises from using the following jsf structure (I'll filter out everything unimportant):
| <t:dataTable var="var"
| rowIndexVar="i"
| value="#{ list }">
|
| <h:column>
| <h:commandLink action="#{ someBean.edit }" immediate="true" value="edit"/>
| </h:column>
|
| <h:column>
| <h:outputText value="#{ var.somefield }" rendered="#{ index != i }"/>
| <h:selectOneMenu value="#{ current.somefield }" rendered="#{ index == i }">
| <si:selectItems value="#{ combo }" var="v" label="#{ v.somefield }"/>
| </h:selectOneMenu>
| </h:column>
| </t:dataTable>
|
I understand if this code appears a bit unusual, the point is to have both viewing and editing on the same table. The 'edit' method will, among a few other things, set the seam context variable 'index' to the position in the list of the selected item, as to have the second clause 'rendered' return true so to show the selectbox.
I've been working with such pattern, and it behaved nicely using f:selectItems and binding the values to strings. Upon switching to si:selectItems, however, I now get the following error as soon as entering the page:
| javax.faces.el.PropertyNotFoundException: /WEB-INF/test.xhtml @50,118 value="#{ current.somefield }": Target Unreachable, identifier 'current' resolved to null
| at com.sun.facelets.el.LegacyValueBinding.getType(LegacyValueBinding.java:96)
| at org.jboss.seam.selectitems.jsf.SelectItemsComponentHandler.addConverters(SelectItemsComponentHandler.java:64)
| at org.jboss.seam.selectitems.jsf.SelectItemsComponentHandler.onComponentCreated(SelectItemsComponentHandler.java:237)
| at com.sun.facelets.tag.jsf.ComponentHandler.apply(ComponentHandler.java:161)
| at com.sun.facelets.tag.jsf.ComponentHandler.applyNextHandler(ComponentHandler.java:295)
| at com.sun.facelets.tag.jsf.ComponentHandler.apply(ComponentHandler.java:165)
| at com.sun.facelets.tag.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:47)
| at com.sun.facelets.tag.jsf.ComponentHandler.applyNextHandler(ComponentHandler.java:295)
| at com.sun.facelets.tag.jsf.ComponentHandler.apply(ComponentHandler.java:165)
| at com.sun.facelets.tag.CompositeFaceletHandler.apply(CompositeFaceletHandler.j
| ...
|
The outjected object 'current' is set only after the 'edit' method is invoked. So it makes sense that such error would occur if I was trying to show the combo upon first entering the page. Note, though, that the 'rendered' clause will return false in this occasion - i only want to see the combo after calling 'edit'. It seems si:selectItems attempts to evaluate the value of my h:selectOneMenu, whether or not it should be rendered, and it ends up breaking the code. Is there any way to achieve the behavior I want?
Much obliged,
Luis
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985462#3985462
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985462
19Â years, 7Â months
[Clustering/JBoss] - Re: Singleton persistence archive, datasource?
by huberth
First of all, thanks alot for the prompt replies!
And in response to:
1) Thanks, I'll make sure I do that.
2) The jboss-service.xml is just a stub (empty server tag), as we rely exclusively on annotations. Here are the annotations, though:
@Management(DatabaseManager.class)
| @Service(objectName = "my.domain:service=DatabaseManager")
| @RemoteBinding(jndiBinding = DatabaseManager.JNDI_NAME)
| @Depends("jboss.ha:service=HASingletonDeployer,type=Barrier")
|
The create method, for now, just logs that it is being called.
The start method finds the MainDeployer (MBeanServerLocator.locateJBoss, MBeanServerInvocationHandler.newProxyInstance, objectName="jboss.system:service=MainDeployer", etc), and calls deploy on it, passing the directory's url (file:/..../server/default/deploy-db/).
The stop method is the same as start, except, of course, it calls undeploy.
3) Changing the dependency works. Everything seems to come up without incident. Given your comment in 2) about it being odd that it worked differently, I presume that even if I go the barrier-controller route, it'd be wise to keep this dependency, yes?
I'd like to go with the barrier-controller as it gives me more precise control over the timing of the replication management tasks relative to shutting down or starting up the db services.
4) It definitely does not call create until the subsequent switch-over. Here's the stack trace at the point at which my create method is called:
Thread "AsynchKeyChangeHandler Thread"@4,007 in group "jboss" status: RUNNING
| create():49, my.domain.databasemanager.DatabaseManagerMBean
| invoke0():-1, sun.reflect.NativeMethodAccessorImpl
| invoke():39, sun.reflect.NativeMethodAccessorImpl
| invoke():25, sun.reflect.DelegatingMethodAccessorImpl
| invoke():585, java.lang.reflect.Method
| invokeNext():109, org.jboss.aop.joinpoint.MethodInvocation
| invoke():54, org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor
| invokeNext():98, org.jboss.aop.joinpoint.MethodInvocation
| invoke():47, org.jboss.ejb3.AllowedOperationsInterceptor
| invokeNext():98, org.jboss.aop.joinpoint.MethodInvocation
| invokeInOurTx():79, org.jboss.aspects.tx.TxPolicy
| invoke():192, org.jboss.aspects.tx.TxInterceptor$Required
| invokeNext():98, org.jboss.aop.joinpoint.MethodInvocation
| invoke():76, org.jboss.aspects.tx.TxPropagationInterceptor
| invokeNext():98, org.jboss.aop.joinpoint.MethodInvocation
| invoke():78, org.jboss.aspects.security.AuthenticationInterceptor
| invokeNext():98, org.jboss.aop.joinpoint.MethodInvocation
| invoke():47, org.jboss.ejb3.ENCPropagationInterceptor
| invokeNext():98, org.jboss.aop.joinpoint.MethodInvocation
| invoke():106, org.jboss.ejb3.asynchronous.AsynchronousInterceptor
| invokeNext():98, org.jboss.aop.joinpoint.MethodInvocation
| localInvoke():181, org.jboss.ejb3.service.ServiceContainer
| localInvoke():142, org.jboss.ejb3.service.ServiceContainer
| invoke():168, org.jboss.ejb3.service.ServiceMBeanDelegate
| invoke():164, org.jboss.mx.server.RawDynamicInvoker
| invoke():659, org.jboss.mx.server.MBeanServerImpl
| invoke():995, org.jboss.system.ServiceController$ServiceProxy
| create():-1, $Proxy0
| create():330, org.jboss.system.ServiceController
| invoke0():-1, sun.reflect.NativeMethodAccessorImpl
| invoke():39, sun.reflect.NativeMethodAccessorImpl
| invoke():25, sun.reflect.DelegatingMethodAccessorImpl
| invoke():585, java.lang.reflect.Method
| invoke():155, org.jboss.mx.interceptor.ReflectedDispatcher
| dispatch():94, org.jboss.mx.server.Invocation
| invoke():86, org.jboss.mx.server.Invocation
| invoke():264, org.jboss.mx.server.AbstractMBeanInvoker
| invoke():659, org.jboss.mx.server.MBeanServerImpl
| invoke():210, org.jboss.mx.util.MBeanProxyExt
| create():-1, $Proxy128
| installMBean():109, org.jboss.ejb3.JmxKernelAbstraction
| registerManagementInterface():352, org.jboss.ejb3.service.ServiceContainer
| start():92, org.jboss.ejb3.service.ServiceContainer
| invoke0():-1, sun.reflect.NativeMethodAccessorImpl
| invoke():39, sun.reflect.NativeMethodAccessorImpl
| invoke():25, sun.reflect.DelegatingMethodAccessorImpl
| invoke():585, java.lang.reflect.Method
| startService():99, org.jboss.ejb3.ServiceDelegateWrapper
| jbossInternalStart():289, org.jboss.system.ServiceMBeanSupport
| jbossInternalLifecycle():245, org.jboss.system.ServiceMBeanSupport
| invoke():-1, sun.reflect.GeneratedMethodAccessor2
| invoke():25, sun.reflect.DelegatingMethodAccessorImpl
| invoke():585, java.lang.reflect.Method
| invoke():155, org.jboss.mx.interceptor.ReflectedDispatcher
| dispatch():94, org.jboss.mx.server.Invocation
| invoke():86, org.jboss.mx.server.Invocation
| invoke():264, org.jboss.mx.server.AbstractMBeanInvoker
| invoke():659, org.jboss.mx.server.MBeanServerImpl
| invoke():978, org.jboss.system.ServiceController$ServiceProxy
| start():-1, $Proxy0
| start():417, org.jboss.system.ServiceController
| start():435, org.jboss.system.ServiceController
| invoke():-1, sun.reflect.GeneratedMethodAccessor9
| invoke():25, sun.reflect.DelegatingMethodAccessorImpl
| invoke():585, java.lang.reflect.Method
| invoke():155, org.jboss.mx.interceptor.ReflectedDispatcher
| dispatch():94, org.jboss.mx.server.Invocation
| invoke():86, org.jboss.mx.server.Invocation
| invoke():264, org.jboss.mx.server.AbstractMBeanInvoker
| invoke():659, org.jboss.mx.server.MBeanServerImpl
| start():194, org.jboss.system.ServiceMBeanSupport
| startBarrier():334, org.jboss.system.BarrierController
| handleNotification2():313, org.jboss.system.BarrierController
| handleNotification():403, org.jboss.system.ListenerServiceMBeanSupport
| invoke():-1, sun.reflect.GeneratedMethodAccessor3
| invoke():25, sun.reflect.DelegatingMethodAccessorImpl
| invoke():585, java.lang.reflect.Method
| invoke():153, org.jboss.mx.notification.NotificationListenerProxy
| handleNotification():-1, $Proxy101
| handleNotification():127, org.jboss.mx.util.JBossNotificationBroadcasterSupport
| sendNotification():110, org.jboss.mx.util.JBossNotificationBroadcasterSupport
| sendNotificationToLocalListeners():354, org.jboss.ha.jmx.HAServiceMBeanSupport
| sendLocalNotification():213, org.jboss.ha.singleton.HASingletonSupport
| makeThisNodeMaster():200, org.jboss.ha.singleton.HASingletonSupport
| partitionTopologyChanged():133, org.jboss.ha.singleton.HASingletonSupport
| replicantsChanged():243, org.jboss.ha.jmx.HAServiceMBeanSupport$1
| notifyKeyListeners():844, org.jboss.ha.framework.server.DistributedReplicantManagerImpl
| processEvent():386, org.jboss.ha.framework.server.DistributedReplicantManagerImpl
| run():107, org.jboss.ha.framework.server.AsynchEventHandler
| run():595, java.lang.Thread
|
Getting the create method called at system startup would be nice so I don't have to create yet another MBean just to know that the system started up.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985460#3985460
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985460
19Â years, 7Â months
[Security & JAAS/JBoss] - Re: Attempt to get JBoss to call my custom login module
by jcollins914
Thanks jaikiran for your gratuitous effort.
"jaikiran" wrote :
| You have the "Code" button which you can use while posting to wrap those contents in a code block to avoid the mess.
|
Thanks, I'll use the code button from now on.
"jaikiran" wrote :
| Now you have secured this servlet using BASIC authentication and a custom login module. Apart from the webservice part this appears to be an attempt to secure the servlet. It should not matter that the servlet is being used by webservice. Am i right?
|
This is my understanding as well, although I've never secured a servlet before, (or an EJB)... I rarely even lock my car... --so I could be way off here, but I think in large part, this gets to the essence of my question, --can I even use declarative security to secure my web service endpoint in the form of a web-method through JBossWS...
"jaikiran" wrote :
| If yes, then when you type in the URL: http://localhost:8080/CentricityPractice/CPWebService do you see the pop up asking for user name and password(since you are using BASIC authentication)?
|
Thanks, I thought so too, but no sale. Referencing that url from a browser simply lists the exposed web service(s), no log in. What I would prefer is to not have a login-config element in my web.xml at all, (or however I would otherwise accomplish the following goal). I am in hopes that I can utilize information that the client sends over in the soap header to obtain details for the login to be performed through my custom login module. In other words, I don't want a BASIC login module to "pop up" requesting a login, and neither do I want a FORM login to allow me to configure my own custom login screen. I want the server code to be able to obtain information from the soap message header, to be used in the custom login module, without any user interaction. I put the login-config BASIC block in there as an attempt to see if I could get a reaction out of the login what-so-ever... Alas no. My current login module, although poised to do so, currently doesn't peer into the soap header, but seeks to just "return true" from the login() method. It should not require an actual login in order to just be called, no?
"jaikiran" wrote :
| Also, have you written any debug log messages in your own custom login module so as to figure out whether the control has been forwarded to it?
|
Yes, definitely. Every method prints out a lot of exclamation points, and a message saying it has been entered. I have also a breakpoint on the first line of each method in my GEHCLoginModule, and am running the application server in debug mode. Stopping at one of those breakpoints, or finding the exclamation points in my console output, would cause much rejoicing. --No sign of them yet.
Continued appreciation.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985453#3985453
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985453
19Â years, 7Â months