Re: BeanShell and Class: x not in namespace
"Florin T.PATRASCU" <[email protected]> Fri, 16 Jun 2006 21:31:26 -0400
| Newsgroups | gmane.comp.java.jpublish.devel |
|---|---|
| Message-ID | <[email protected]> |
--===============1847305044== Content-Type: multipart/alternative; boundary=Apple-Mail-2-401995071 --Apple-Mail-2-401995071 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi guys, On 16-Jun-06, at 10:16 AM, Lateef Jackson wrote: > 4) Finally every WAR you have you have to have all the jar copied > into the WEB-INF/lib separately. Yes this is the way it always works. The shared classloader architecture used by JBoss is not so friendly. Except the method 4) suggested by Lateef, there is also one which always works, a not so well known method: using the MANIFEST.MF/Class-Path. The MANIFEST.MF referred to is the one inside the ejb or war archive and NOT the one directly in the ear archive. You may want to read more by following this link: http://java.sun.com/docs/books/tutorial/deployment/jar/ From a different perspective, using EARs where the entire web app is archived, doesn't offer the kind of flexibility JPublish was designed for. While the binary code can be easily "protected" by deploying it as .jar(s) in the WEB-INF/lib folder, the access to the dynamic content should be granted to the Designers, so they can really manage the dynamic/static component of the web app served by JPublish. However, if your app is one composed by a relatively static content, then yes .. you can jail ;) its contents in EARs and so on. I am going to look at the Groovy story now and I'll return with some feedback. Thanks for using JPublish! -florin --Apple-Mail-2-401995071 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 <HTML><BODY style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; = -khtml-line-break: after-white-space; ">Hi guys,<DIV><BR><DIV> <SPAN = class=3D"Apple-style-span" style=3D"border-collapse: separate; = border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Monaco; = font-size: 13px; font-style: normal; font-variant: normal; font-weight: = normal; letter-spacing: normal; line-height: normal; text-align: auto; = -khtml-text-decorations-in-effect: none; text-indent: 0px; = -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = white-space: normal; widows: 2; word-spacing: 0px; = "></SPAN></DIV><DIV><DIV>On 16-Jun-06, at 10:16 AM, Lateef Jackson = wrote:</DIV><BR class=3D"Apple-interchange-newline"><BLOCKQUOTE = type=3D"cite"><SPAN class=3D"Apple-style-span" style=3D"border-collapse: = separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: = Monaco; font-size: 13px; font-style: normal; font-variant: normal; = font-weight: normal; letter-spacing: normal; line-height: normal; = text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: = 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = white-space: normal; widows: 2; word-spacing: 0px; ">4) Finally every = WAR you have you have to have all the jar copied into the WEB-INF/lib = separately.</SPAN></BLOCKQUOTE></DIV><BR></DIV><DIV>Yes this is the way = it always works. The shared classloader architecture used by JBoss is = not so friendly. Except the method 4) suggested by Lateef, there is also = one which always works, a not so well known method: using = the=A0MANIFEST.MF/Class-Path.=A0The MANIFEST.MF referred to is the one = inside the ejb or war archive and NOT the one directly in the ear = archive. You may want to read more by following this link:=A0<FONT = class=3D"Apple-style-span" face=3D"Helvetica" size=3D"3"><SPAN = class=3D"Apple-style-span" style=3D"font-size: 12px;"><A = href=3D"http://java.sun.com/docs/books/tutorial/deployment/jar/">http://ja= va.sun.com/docs/books/tutorial/deployment/jar/</A></SPAN></FONT></DIV><DIV= ><FONT class=3D"Apple-style-span" face=3D"Helvetica" size=3D"3"><SPAN = class=3D"Apple-style-span" style=3D"font-size: 12px;"><BR = class=3D"khtml-block-placeholder"></SPAN></FONT></DIV><DIV>=46rom a = different perspective, using EARs where the entire web app is archived, = doesn't offer the kind of flexibility JPublish was designed for. While = the binary code can be easily "protected" by deploying it as .jar(s) in = the WEB-INF/lib folder, the access to the dynamic content should be = granted to the Designers, so they can really manage the dynamic/static = component of the web app served by JPublish. However, if your app is one = composed by a relatively static content, then yes .. you can jail ;) its = contents in EARs and so on.</DIV><DIV><BR = class=3D"khtml-block-placeholder"></DIV><DIV>I am going to look at the = Groovy story now and I'll return with some feedback.</DIV><DIV><BR = class=3D"khtml-block-placeholder"></DIV><DIV>Thanks for using = JPublish!</DIV><DIV>-florin</DIV></BODY></HTML>= --Apple-Mail-2-401995071-- --===============1847305044== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============1847305044== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Jpublish-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jpublish-developer --===============1847305044==--