Re: [jboss-user] [JBoss Microcontainer Development] - ShrinkWrapDeployer
by John Bailey
John Bailey [http://community.jboss.org/people/johnbailey] replied to the discussion
"ShrinkWrapDeployer"
To view the discussion, visit: http://community.jboss.org/message/540890#540890
--------------------------------------------------------------
ALR and I discussed this a couple weeks ago. One thought I had was to change the flow of the deployers to better handle/fit the VFS mounting model. This was also discussed during the VFS3 integration work. It would be ideal if the structure deployers were not forced to execute prior to invoking the rest of the deployers, but rather functioned as any other deployer based on inputs/outputs. The idea was to initiate the deployment with some specific metadata that describes deployment (file, directory, SWArchive, etc..). There would then be a series of deployers which look for these specific metadata types and would invoke the proper VFS mount/unmount operations for the deployment. Once the mount is performed, there would be an output that could be attached to inform the structure deployer to get fired. The structure deployes would get fired and the process would continue its normal flow.
The key change is to align the structure deployers with the Deployer API and actually have deploy and undeploy operations. Then you can introduce deployers in front of structure determination to handle proper mounting With this change, all that would be needed to integrate the ShrinkWrap Archive deployment would be to create the deployment (in embedded, TorqueBox, etc.) with an attachment that would cause a special mounting deployer to pick up and mount the ArchiveFileSystem as apposed to the normal filesystem based mounting deployers.
I realize this is a bit larger change than is being discussed with regard to the SW archives, but it also seems like it would better support the mount operations. Best of all, it would get rid of the Automounter.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/540890#540890]
Start a new discussion in JBoss Microcontainer Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years
[JBoss Portal] - Public render parameters not always available in render phase
by Mauro Lopez
Mauro Lopez [http://community.jboss.org/people/mauro.lopez] created the discussion
"Public render parameters not always available in render phase"
To view the discussion, visit: http://community.jboss.org/message/540886#540886
--------------------------------------------------------------
"Hello":
The following portlet example shows the value of the "renderParameter" PRP (public render parameter), and if the submit button is pressed, sets it to the value "Hello":
public class MyPortlet extends GenericPortlet {
private static final String RENDER_PARAMETER = "renderParameter";
@Override
protected void doView(RenderRequest request, RenderResponse response)
throws PortletException, IOException {
response.setContentType("text/html");
String actionURL = response.createActionURL().toString();
PrintWriter out = response.getWriter();
out.print("render parameter value is: " + request.getParameter(RENDER_PARAMETER));
out.print("<form method=POST action=" + actionURL + "><input type=submit value=Subir></form>");
}
@Override
public void processAction(ActionRequest request, ActionResponse response)
throws PortletException, IOException {
response.setRenderParameter(RENDER_PARAMETER, "Hello");
}
}
<portlet>
<portlet-name>MyPortlet</portlet-name>
<portlet-class>test.MyPortlet</portlet-class>
<expiration-cache>-0</expiration-cache>
<supports>
<mime-type>text/html</mime-type>
<portlet-mode>VIEW</portlet-mode>
</supports>
<portlet-info>
<title>MyPortlet</title>
</portlet-info>
<supported-public-render-parameter>renderParameter</supported-public-render-parameter>
</portlet>
<public-render-parameter>
<identifier>renderParameter</identifier>
<qname xmlns:x="http://www.ideasoft.biz/public-render-parameters">x:renderParameter</qname>
</public-render-parameter>
After the button is pressed, the PRP is set, and (at least) the following actions will NOT UNSET it:
1. maximizing/restoring the portlet window
2. playing with other portlets (of course, the other portlets do not use this particular PRP)
3. Navigate to other pages, and then return (e.g. clicking pages in the navigation bar)
This is, I think, the expected behaviour, since any PRP (as any other render parameter) should be available, once set, after any subsequent render phase.
Well, this was the situation with jboss portal 2.7.0, but in portal 2.7.2, when you play around with the pages in the navigation bar, the PRP is lost.
Is this a bug? Do you know how to get 2.7.2 behave like 2.7.0?
Thanks!
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/540886#540886]
Start a new discussion in JBoss Portal at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years
Re: [jboss-user] [JBoss Microcontainer Development] - ShrinkWrapDeployer
by Andrew Rubinger
Andrew Rubinger [http://community.jboss.org/people/ALRubinger] replied to the discussion
"ShrinkWrapDeployer"
To view the discussion, visit: http://community.jboss.org/message/540878#540878
--------------------------------------------------------------
Realtime discussion:
(04:10:23 PM) ALR@MSN: About ShrinkWrapDeployer: let me ask you:
(04:10:30 PM) Ales: shoot
(04:10:35 PM) ALR@MSN: Where's the component that bridges VFS inputs to the Deployers ?
(04:10:47 PM) Ales: vfs inputs?
(04:10:51 PM) ALR@MSN: VirtualFile.
(04:10:55 PM) ALR@MSN: How do you deploy one?
(04:11:07 PM) Ales: VFSDeployment extends Deployment
(04:11:17 PM) ALR@MSN: Right. Where does VFSDeployment live?
(04:11:27 PM) Ales: jboss-deployers-vfs-spi
(04:11:42 PM) ALR@MSN: Where should the component that bridges SW Archive inputs to Deployers be?
(04:12:02 PM) Ales: hmmm ...
(04:12:13 PM) ALR@MSN: Say it.
(04:12:16 PM) Ales: hehe
(04:12:16 PM) ALR@MSN: jboss-deployers-shrinkwrap. ;D
(04:12:19 PM) Ales: hmmmm ...
(04:12:21 PM) Ales: nope
(04:12:24 PM) ALR@MSN: Hahahahaha!
(04:12:33 PM) Ales: vfs spi is really a spi ... and it has actual impl
(04:12:45 PM) Ales: whereas your sw stuff is wrapper/facade
(04:12:50 PM) ALR@MSN: ShrinkWrapDeployers is just an impl.
(04:12:56 PM) ALR@MSN: The SPI part is yes, a wrapper.
(04:13:03 PM) ALR@MSN: But there's only one reason why:
(04:13:21 PM) ALR@MSN: I need to mount and unmount archives as VFS alongside the deployment/undeployment process
(04:13:36 PM) ALR@MSN: So I can't make the equivalent of VFSDeploymentFactory and call it a day.
(04:13:45 PM) Ales: true
(04:13:48 PM) ALR@MSN: On undeploy we need to unmount.
(04:14:18 PM) Ales: your SW is just another api for VFS
(04:14:27 PM) ALR@MSN: Correct.
(04:14:32 PM) Ales: hence it's a wrapper/facade
(04:14:39 PM) ALR@MSN: Well, no.
(04:14:45 PM) ALR@MSN: SW doesn't wrap VFS.
(04:14:47 PM) Ales: if we didn't have vfs, then I would say yes, put it into deployers
(04:14:51 PM) Ales: but we a;ready have vfs
(04:14:53 PM) ALR@MSN: We have, however, a VFS adaptor
(04:15:17 PM) Ales: yeah, you need to adapt Archive to VFSDeployment
(04:15:27 PM) ALR@MSN: Right.
(04:15:34 PM) Ales: == facade
(04:15:44 PM) ALR@MSN: And if not for the unmounting, I could do it the same way as in VFSDeploymentFactory
(04:15:58 PM) ALR@MSN: With no new deploy/undeploy APIs.
(04:16:18 PM) Ales: why's that?
(04:16:33 PM) Ales: why is mounting/unmoounting an issue?
(04:16:37 PM) ALR@MSN: VFSDeployment deployment = ShrinkWrapDeploymentFactory.createDeployment(archive); // Easy
(04:16:49 PM) ALR@MSN: Because I need to mount it using a ShrinkWrap extension.
(04:16:58 PM) ALR@MSN: ArchiveFileSystem.
(04:17:10 PM) ALR@MSN: Which is what enables VFS to read SW
(04:17:41 PM) ALR@MSN: You guys do inspection to mountReal or mountJar or something.
(04:17:47 PM) Ales: aha, so when asked if it's already mounted, it says true
(04:17:54 PM) Ales: hence it doesn't do mounting
(04:18:01 PM) ALR@MSN: "it"?
(04:18:17 PM) Ales: mounting mechanism inside deployers
(04:18:21 PM) ALR@MSN: After it comes into MainDeployer, nothing will mount it, yes.
(04:18:32 PM) ALR@MSN: We mount.
(04:18:56 PM) Ales: if you didn't?
(04:19:06 PM) ALR@MSN: Then something in deployers would need to.
(04:19:10 PM) Ales: i guess structiure deployers would try and fail?
(04:19:14 PM) ALR@MSN: And unmount it when undeployed.
(04:19:26 PM) ALR@MSN: Right. getChildren would return nothing.
(04:19:31 PM) Ales: no
(04:19:53 PM) Ales: see AbstractVFSArchiveStructureDeployer
(04:20:57 PM) ALR@MSN: http://fisheye.jboss.org/browse/JBossAS/projects/jboss-deployers/trunk/de... http://fisheye.jboss.org/browse/JBossAS/projects/jboss-deployers/trunk/de...
(04:21:01 PM) ALR@MSN: So why "no"?
(04:21:50 PM) Ales: it would try to mount
(04:21:53 PM) Ales: and probably fail
(04:21:55 PM) Ales: or not?
(04:21:58 PM) ALR@MSN: Oh, right
(04:22:05 PM) ALR@MSN: Because it'd be using the wrong FileSystem.
(04:22:09 PM) Ales: yes
(04:22:47 PM) ALR@MSN: I have no qualms with removing the wrapper API
(04:22:59 PM) ALR@MSN: If you wanna make structure deployers figure out how to mount it properly
(04:22:59 PM) Ales: perhaps this should made possible
(04:23:04 PM) Ales: yes
(04:23:05 PM) Ales: exactly
(04:23:10 PM) ALR@MSN: But I assumed you didn't wanna back that logic in.
(04:23:21 PM) Ales: didn't think of that
(04:23:41 PM) Ales: how would we recognize which FS we need to mount?
(04:23:43 PM) Ales: hmmm ...
(04:23:45 PM) ALR@MSN: No idea.
(04:23:48 PM) Ales: :-)
(04:24:07 PM) ALR@MSN: VirtualFile is just a pointer.
(04:24:15 PM) ALR@MSN: You'd have to rely on exceptions for flow control.
(04:24:25 PM) ALR@MSN: ie. try and catch the exception if it's not a SW archive.
(04:24:33 PM) ALR@MSN: Which is no good solution.
(04:25:07 PM) Ales: i'll think about it a bit
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/540878#540878]
Start a new discussion in JBoss Microcontainer Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years