Blueprints JBoss integration
Hello,
i was trying the whole day to get the Ajax Blueprint Components to work in Jboss,
without any success(in Glassfish its no problem but cant change to glassfish).
Does anyone knows if its possible at all(shoudl be - both are application server)
to get JBoss, Myfaces and Blueprint to work?
Think it has sth to do with that jboss want ear files(i noticed only war files are created and deployed from blueprint build)- only a guess.
In meantime i try the tomahawk components as replacement.
Thank your very much,
Holger
Message was edited by:
Holger_P
[622 byte] By [
Holger_Pa] at [2007-10-3 7:53:35]
Hi Holger_P,
I guess there might be a problem with MyFaces. As far as I know
it doesn't support JSF1.2 (JSF1.2 requires JSP2.1 but tomcat doesn't
support that yet).
BluePrints solutions catalog has two kinds of set, one is for
J2EE1.4 and the other is for JavaEE5. So, also depending on
the version of your JBoss, the samples in JavaEE5 catalog
don't work.
yutaa at 2007-7-15 2:55:52 >
Thank u for the quick reply,
ok i will give it another chance and try the J2EE1.4 version(i already did) again,
or trying to upgrade my jboss Server (using vjboss-4.0.4.GA - pretty new i think)
maybe tomorrow i have a more clearsight.
Ifi get anything to work ill posts it here.
I am very interest if anyone got the BluePrints solutions catalog working
on any other application server than glassfish(the buildfiles are glassfish specific i think).
Hi,
If you do get the 1.4 library working on JBOSS, we would like to know any steps you needed to do to port them over. If you blog on the steps or want to contribute a short write up of instructions we could post it on our site so other users could follow the instructions. We have not tried them on JBOSS and if you get it working then it could probably help a lot of other users.
Also, just a related question as we are curious and planning what to do next with the component libraries we have...
--how do you plan to use them?
-are you using them to learn some new things?
--are you using them to build a sample application or school project application?
--are you thinking about using them in a production application?
Anyway, I know you asked us a question, and now I am asking you some questions :-) But it could really help us plan the blueprints projects and tailor them to what people want.
thx,
Sean
Ill start to try out on monday - i hope it will work(after my depressing experience i somehow doubt it will - and i dont want to put to much time in it)
Ill post here if if fail or success and keep u up to date.
Meanwhile i can only say maybe take a look at tomahawk
http://myfaces.apache.org/tomahawk/
Bye , regards,
Holger
After gettin the eviroment up (with all jar) it get on the jsp page.
The calendar icon is rendered, but i cant click it.
When i refresh page after that i get:
FATAL: Could not load 'dojo.io'; last tried '__package__.js'
FATAL: symbol 'popupcalendar' is not defined after loading '__package__.js'
Well this is the point where i give up.
I am really wondering if i did sth wrong , but i got tomahawk working just by copying some jar and it works.
Which browser are you using?It could be a javascript problem in the browser.(or could be tomahawk issue, of course)To narrow down the issue, could you try to clean thebrowser cache and reload the same page?
yutaa at 2007-7-15 2:55:52 >
Hi Holger,
This looks like a Dojo library problem. Is the "web/src" directory in your web application. The "dojo.js" script file uses the "__package__.js" scripts to load the necessary libraries from dojo "src" directory.
The dojo directory gets unzipped into the build directory when the application is packaged during the application's build process and a war is created.
Please let us know...
Thanks - Mark
Hello,
if i look into bp-ui-14.jar all necessary script seems to be contained there.
But ill try what u suggest.
If i understand u right the unzipped content of "dojo.zip" should be included in the war file in the directory /web/src?
Seems a strange location,
Shouldnt it be under /WEB-INF ?
Can u give me the correct path and directory name(if it was -sorry)?
Thank u very much
Message was edited by:
Holger_P
Hi Holger,
Sorry to confuse you, the dojo libraries are in the bp-ui-14.jar in the meta-inf/dojo directory. I erroneously thought you where trying to use the libraries in its raw source form. My mistake :-(
The dojo libraries are bundled in the bp-ui-14.jar and are accessed through the shale-remoting phaselistener.
How is your faces servlet being mapped? You can find this information in your web.xml standard deployment descriptor. Are you using suffix identifier (like .jsf) or are you using a path map (like /faces)? If you are using a suffix map then there is a bug we have encountered with shale-remoting on locating extra dojo packages, so please put the path mapping ahead of the suffix mapping in your deployment descriptor and try the url again.
If not you aren't using the suffix mapping, then you should be able to access the dojo.js file directly. So for example, if you deployed the bp-ui-14.jar and the supporting libraries (which are shale-remoting.jar and commons-logging-1.1.jar) in a web application, you should be able to access the dojo.js file using the following pseudo URL http://host:port/contextroot/faces/static/META-INF/dojo/dojo.js. So in the case of the auto-complete example application, the URL for the dojo library would be http://localhost:8080/bp-auto-complete/faces/static/META-INF/dojo/dojo.js.
Please make sure that this works before we continue debugging...
Sorry for any confusion - Thanks - Mark
Ok after changing to path mapping it worked.
Only 1 Mapping is allowed, if i declare any suffix mapping, it dont work anymore(even when accessing the path based url).
wont work:
<servlet-mapping>
<servlet-name>Faces Servlet</servlet-name>
<url-pattern>*.seam</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>Faces Servlet</servlet-name>
<url-pattern>/faces/*</url-pattern>
</servlet-mapping>
Ok i common cases this would be a solution(changing to path mapping).
But now it gets messed up, i picked the wrong libraries i guess.
I will explain:
1) I am using facelets (https://facelets.dev.java.net/)
This means i cant use any "old" taglibs, i am already thinking about going
back to old jsp(even when i dont like jsp - facelets is better ), nice new world...
2) I cant use any path based url, i need to get it work with a suffix url.
(see reason 1..., and i dont like path based mappings)
So i need to get it to work with facelets and with suffix url mapping.
Cant i just copy the dojo files somewhere to WEB/INF and remove them from the jar so they can be found directly?
That would solve the suffix mapping problem.
Thank u very much,
Holger
Message was edited by:
Holger_P
Hi Holger,
You can still have your suffix based mapping for other things, it is just that shale-remoting needs to use a path based mapping to access the resource.
So if you put the path based mapping first in your descriptor then shale-remoting will use it as part of the url. To do this, your deployment descriptor should look like:
<servlet-mapping>
<servlet-name>Faces Servlet</servlet-name>
<url-pattern>/faces/*</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>Faces Servlet</servlet-name>
<url-pattern>*.seam</url-pattern>
</servlet-mapping>
When shale-remoting utilities are used in the component's renderer, the access url will use the path based method and be fully qualified.
You can look in the pages html source to see that this is true.
You can also use the the suffix method to access your pages, but the mapping exists in your deployment descriptor.
You can't just put the dojo resources in your web application, because the link to the javascript files are fully qualified. You could get this to work with a hack, but is should work if you implement the changes above.
Please let us know how this works out.
Hope this helps - Thanks - Mark
Ok i changed my mind, changing to pathmapping took me 1 minute and i dont had to change any code in my app.
Well ok now its only the stupid facelets stuff , think noone can help me with this,
in meantime ill try to include jsp pages from facelets pages, jsut playing around
Message was edited by:
Holger_P
<servlet-mapping>
<servlet-name>Faces Servlet</servlet-name>
<url-pattern>/faces/*</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>Faces Servlet</servlet-name>
<url-pattern>*.seam</url-pattern>
</servlet-mapping>
noticed i made mistake in order of declaring ^^
Changed it but still not working.Well see post above , changed to path mapping
Thank u very much ill give u the dollars ^^
Message was edited by:
Holger_P
Message was edited by:
Holger_P
Sigh after further testing, i get the problems i started with , even with path based mapping.
in my serverlogs:
org.apache.catalina.connector.Request.getDateHeader(Request.java:1791)
org.apache.catalina.connector.RequestFacade.getDateHeader(RequestFacade.java:630)
org.apache.shale.remoting.impl.AbstractResourceProcessor.ifModifiedSince(AbstractResourceProcessor.java:347)
org.apache.shale.remoting.impl.AbstractResourceProcessor.process(AbstractResourceProcessor.java:101)
org.apache.shale.remoting.faces.RemotingPhaseListener.afterPhase(RemotingPhaseListener.java:102)
org.apache.myfaces.lifecycle.LifecycleImpl.informPhaseListenersAfter(LifecycleImpl.java:536)
org.apache.myfaces.lifecycle.LifecycleImpl.restoreView(LifecycleImpl.java:164)
org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:66)
javax.faces.webapp.FacesServlet.service(FacesServlet.java:106)
org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:144)
org.jboss.seam.servlet.SeamExceptionFilter.doFilter(SeamExceptionFilter.java:45)
org.jboss.seam.servlet.SeamRedirectFilter.doFilter(SeamRedirectFilter.java:30)
org.ajax4jsf.framework.ajax.xmlfilter.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:67)
org.ajax4jsf.framework.ajax.xmlfilter.BaseFilter.doFilter(BaseFilter.java:223)
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
Well lets forget about it.
null
When jboss supports JSF1.2 I will try to use it with our latest libraries myself and report any findings. If there is a problem that I can fix, I will do so. But there is also the possibility of a problem in their JSF implementation. If that is the case, I will file bugs for jboss to fix.
Thanks - Mark
