[JBoss Seam] - Using rich:datascroller With Seam and Hibernate Pagination
by neilac333
I prefer to handle all my pagination on the server with Hibernate, but I also want to use the <rich:datascroller> component. My Seam component "knows" the following information:
1) The total number of page results
2) The current page number of results
3) The desired number of results per page
4) The search results for the current page
For example, let's say I search for something that returns 43 results, and the user wants 10 results per page. The component knows that there are 5 total pages, that there are 10 results per page, and which results go with which page (page 0 has results 0-9 and page 4 has results 40-42 for example). The component also serves out the results one page at a time.
All the rich:datascroller needs to know is that it is getting one page of five, but it can retrieve information about the entire result set (like total pages) from the Seam component.
How do I use rich:datascroller with the information I have in my Seam component to facilitate pagination? Is this even possible without essentially writing my own component?
Thanks.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4122798#4122798
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4122798
18 years, 6 months
[JBossWS] - Dispatch WS-Security Bug
by cavani
I was trying to use WS-Security with JAX-WS Dispatch from version 2.0.2 but the response message returned still encrypted (it works with generated client). After some debug and code reading, I think that I figured it out.
On DispatchImpl, the code is:
| (...) msgContext.put(MessageContextJAXWS.MESSAGE_OUTBOUND_PROPERTY, Boolean.TRUE);
|
| QName portName = epMetaData.getPortName();
| try
| {
| // Call the request handlers
| boolean handlerPass = callRequestHandlerChain(portName, handlerType[0]);
| handlerPass = handlerPass && callRequestHandlerChain(portName, handlerType[1]);
| handlerPass = handlerPass && callRequestHandlerChain(portName, handlerType[2]);
|
| // Handlers might have replaced the message
| reqMsg = (SOAPMessageImpl)msgContext.getSOAPMessage();
|
| MessageAbstraction resMsg = null;
| if (handlerPass)
| {
| Map<String, Object> callProps = new HashMap<String, Object>(getRequestContext());
| EndpointInfo epInfo = new EndpointInfo(epMetaData, targetAddress, callProps);
| resMsg = getRemotingConnection().invoke(reqMsg, epInfo, false);
|
| // Call the response handler chain, removing the fault type entry will not call handleFault for that chain
| handlerPass = callResponseHandlerChain(portName, handlerType[2]);
| faultType[2] = null;
| handlerPass = handlerPass && callResponseHandlerChain(portName, handlerType[1]);
| faultType[1] = null;
| handlerPass = handlerPass && callResponseHandlerChain(portName, handlerType[0]);
| faultType[0] = null;
| }
| (...)
|
But on CommonClient / ClientImpl, the similar code block is a bit different, but, essentially, the direction change after invocation.
| (...)
| DirectionHolder direction = new DirectionHolder(Direction.OutBound);
|
| // Get the order of pre/post handlerchains
| HandlerType[] handlerType = new HandlerType[] { HandlerType.PRE, HandlerType.ENDPOINT, HandlerType.POST };
| HandlerType[] faultType = new HandlerType[] { HandlerType.PRE, HandlerType.ENDPOINT, HandlerType.POST };
|
| QName portName = epMetaData.getPortName();
| try
| {
| // Get the binding from the provider
| CommonBinding binding = (CommonBinding)getCommonBindingProvider().getCommonBinding();
| binding.setHeaderSource(this);
|
| // Create the invocation and sync the input parameters
| epInv = new EndpointInvocation(opMetaData);
| epInv.initInputParams(inputParams);
|
| // Set the required outbound properties
| setOutboundContextProperties();
|
| // Bind the request message
| MessageAbstraction reqMessage = binding.bindRequestMessage(opMetaData, epInv, unboundHeaders);
|
| // Add possible attachment parts
| addAttachmentParts(reqMessage);
|
| // Call the request handlers
| boolean handlerPass = callRequestHandlerChain(portName, handlerType[0]);
| handlerPass = handlerPass && callRequestHandlerChain(portName, handlerType[1]);
| handlerPass = handlerPass && callRequestHandlerChain(portName, handlerType[2]);
|
| // Handlers might have replaced the message
| reqMessage = msgContext.getMessageAbstraction();
|
| if (handlerPass)
| {
| String targetAddress = getTargetEndpointAddress();
|
| // Fall back to wsa:To
| AddressingProperties addrProps = (AddressingProperties)msgContext.get(JAXWSAConstants.CLIENT_ADDRESSING_PROPERTIES_OUTBOUND);
| if (targetAddress == null && addrProps != null && addrProps.getTo() != null)
| {
| AddressingConstantsImpl ADDR = new AddressingConstantsImpl();
| String wsaTo = addrProps.getTo().getURI().toString();
| if (wsaTo.equals(ADDR.getAnonymousURI()) == false)
| {
| try
| {
| URL wsaToURL = new URL(wsaTo);
| log.debug("Sending request to addressing destination: " + wsaToURL);
| targetAddress = wsaToURL.toExternalForm();
| }
| catch (MalformedURLException ex)
| {
| log.debug("Not a valid URL: " + wsaTo);
| }
| }
| }
|
| // The endpoint address must be known beyond this point
| if (targetAddress == null)
| throw new WSException("Target endpoint address not set");
|
| Map<String, Object> callProps = new HashMap<String, Object>(getRequestContext());
| EndpointInfo epInfo = new EndpointInfo(epMetaData, targetAddress, callProps);
| if (shouldMaintainSession())
| addSessionInfo(reqMessage, callProps);
|
| SOAPRemotingConnection remotingConnection = new SOAPRemotingConnection();
| MessageAbstraction resMessage = remotingConnection.invoke(reqMessage, epInfo, oneway);
|
| if (shouldMaintainSession())
| saveSessionInfo(callProps, getRequestContext());
|
| // At pivot the message context might be replaced
| msgContext = processPivotInternal(msgContext, direction);
|
| // Copy the remoting meta data
| msgContext.put(CommonMessageContext.REMOTING_METADATA, callProps);
|
| // Associate response message with message context
| msgContext.setMessageAbstraction(resMessage);
| }
|
| setInboundContextProperties();
|
| // Get the return object
| Object retObj = null;
| if (oneway == false && handlerPass)
| {
| // Verify
| if (binding instanceof CommonSOAPBinding)
| ((CommonSOAPBinding)binding).checkMustUnderstand(opMetaData);
|
| // Call the response handler chain, removing the fault type entry will not call handleFault for that chain
| handlerPass = callResponseHandlerChain(portName, handlerType[2]);
| faultType[2] = null;
| (...)
|
This is a bug, right? (sorry if I am wrong)
If so, this can be fixed fro 2.0.3 still?
Thanks,
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4122793#4122793
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4122793
18 years, 6 months