[Design of POJO Server] - Re: VFS issues
by adrian＠jboss.org
The slight difference due to the simplification of the api can be
seen in this example:
Old test
| VFSFactory factory = VFSFactoryLocator.getFactory(rootURL);
| ReadOnlyVFS vfs = factory.getVFS(rootURL);
|
| // Check resolving the root file
| VirtualFile root = vfs.resolveFile("");
|
| // Find the outer.jar
| VirtualFile outerJar = vfs.resolveFile("outer.jar");
|
New test
| VFS vfs = VFS.getVFS(rootURL);
|
| // Check resolving the root file
| VirtualFile root = vfs.findChildFromRoot("");
|
| // Find the outer.jar
| VirtualFile outerJar = vfs.findChildFromRoot("outer.jar");
|
Additionally, the new stuff supports the follow factory methods
which are really just wrappers to the other primitives.
| // establish a context and get a file
| vfs.getVirtualFile(rootURL, "outer.jar");
|
| // Simplified access to the root
| vfs.getRoot(); == vfs.findChildFromRoot("");
|
| // Relative access
| VirtualFile outer = vfs.getVirtualFile(rootURL, "outer.jar");
| vfs.findChild(outer, "META-INF/MANIFEST.MF");
|
| // The latter is really just the simpler
| outer.findChild("META-INF/MANIFEST.MF");
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3969713#3969713
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3969713
19 years, 7 months
[Design of JBoss Portal] - Re: JBOSS Portal, JSF, XHTML and AJAX !!!finally!!! :-)
by dajevtic
Current lifecycle is:
I create an XMLHttpRequest and send it to the portal servlet (either action=2 for simple rendering or action=1 for applying my form values and then retrieving results). In order for the portal servlet to know if it is an ajax request it looks for a request parameter (I called it "lmgajax"). If this request parameter exists then a PortalRequest constructor with isAjax=true is called and then InvokeWindowActionCommand with isAjax is called. Based on that I let the portal do everything else. At the end the InvokeWindowActionCommand instantiates a InvokeWindowRenderCommand (also with ajax=true) in the constructor. When the RenderContext is activated for rendering the page, it checks if it was invoked from an Ajax request. If so, then only the portlet that triggered the Ajax is rendered with decorator = emptyRenderer. The request sent back is then only the inner HTML of the portlet that created the request. That is basically it.
Now I (additionally) want to add some goodies like I mentioned, e.g. specify a target portlet.
For now, any portlet can create an AJAX request sending all its form elements within the AJAX request and be rerendered.
Sorry if I confused you, but it does indeed work on any portlet that sends out an Ajax-Request. Only prerequisite is that the request contains a parameter "lmgajax". lmg being my companies initials, but I don't insist on calling the parameter like that. I could be also "jbossajax" or anything you like. The PortalServlet just needs to know, so we can have that parameter name configured in web.xml...
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3969708#3969708
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3969708
19 years, 7 months
[Design of POJO Server] - Re: VFS issues
by adrian＠jboss.org
I've created an alternative version of the VFS prototype in
org.jboss.virtual
(I didn't want to break EJB3's usage of the org.jboss.vfs).
The main effort is to try to make it consistent
in how it creates virtual files rather having repeated
(but inconsistent) code across the retrieval mechanism.
The org.jboss.virtual is a refactoring of org.jboss.vfs
(I left the original authors in place where relevant).
The other changes are:
1) A split into user wrappers and the real implementation.
User (api) -> Real (spi)
VFS -> VFSContext (old ReadOnlyVFS)
VirtualFile -> VirtualFileHandler (old VirtualFile)
The user api is made of concrete classes that delegate to the spi
The user api is in org.jboss.virtual,
the spi is in org.jboss.virtual.spi
2) VFS also serves as the initial factory (wrapping the locator
with a simpler static api).
3) Abstract support for implementions, basically all you need
to implement is getting the root in the VFSContext
and then (besides the attributes) getChildren() and findChild()
in the VirtualFileHandler.
There is also some simple support for findChild based on
two models:
a) StructureVirtualFileHandler - which bumps through
each context of the path, i.e. com/acme/Blah
is effectively (but more efficiently) turned into
| start.findChild("com").findChild("acme").findChild("Blah");
|
This is what the file vfs does.
b) Simple - where all the entries are known to the root
this is what the jar stuff does.
You don't have to use either of these of course. :-)
4) A cleaner and more expressive query api based on the visitor
pattern. Other simpler queries in the api are wrappers for this.
The default visit impl is based on the getChildren() from the spi
so you don't need to write any of this yourself.
5) Paths work whether they end in a / or not
com/acme/directory/ == com/acme/directory
the only reason for an explicit slash is when you want to
express "contents of directory" rather than the directory,
which isn't relevant for this api.
There is isDirectory() if you need to know what type it is.
Things missing that are in org.jboss.vfs
1) Serialization of the VFS objects
2) Internal caching
3) Support for "search context"
4) Nested jars are unpacked into temp files rather than
in memory byte buffers.
Finally, I've done a lot manual testing, but there is no
complete testsuite. I did port the original tests where relevant
and modified to the new api.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3969706#3969706
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3969706
19 years, 7 months
Virus intercepted
by MAILER-DAEMON＠lists.jboss.org
A message sent from <postmaster(a)lists.jboss.org> to
<jboss-dev-forums(a)lists.jboss.org>
contained Worm.Mydoom.M and has not been delivered.
19 years, 7 months
Virus intercepted
by MAILER-DAEMON＠lists.jboss.org
A message sent from <postmaster(a)lists.jboss.org> to
<jboss-dev-forums(a)lists.jboss.org>
contained Worm.Mydoom.M and has not been delivered.
19 years, 7 months
