Re: BeanShell and Class: x not in namespace

Hmm. The MBean thing sounds interesting. I am familiar with MBeans.
The problem is that the infrastructure is controlled by the (what
else) the infrastructure team. In my opinion (and I hope no spy mice
are listening to this <smile>) they implemented their infrastructure
incorrectly. To shed more light, each application is deployed in its
own "zone". A zone is nothing more than an instance of JBoss running
on a unique port. Therefore, creating an MBean should do the trick.
The thing is their scripts create a session bean that "knows" how to
access your service from the config/properties files that you set up
in your project. The session bean is just a pass-thru to your web app
so I don't see any reason NOT to make it an MBean. Now, the trick is
to convince them of it. (maybe some cheese would do the trick.
Hmm....)

I tried the MANIFEST trick to no avail. I only wanted to try Groovy
because I thought it would "see" all the classes unlike BeanShell. If
I am going to put the Groovy jars at the JBoss level, then I might as
well deploy my classes separately instead and use BeanShell. That
seems to do the trick, though it is not my preferred method.

If you compile a version of your Java 1.5 Groovy with Retroweaver
(http://retroweaver.sourceforge.net/) you would be able to run the
classes in Java 1.4. I did this with another project. The
infrastructure guys "had a cow", but I the "use the right tool for the
job" mentality and Java 1.5 with its generics was necessary. Hey, I'm
"rebel geek" for nothing. <smile>

I really want to thank you guys for the support. I will grab the
latest JP3 and try it. I hope to report something positive.

Regards

------------------------------------------
Be A Rebel

On 6/18/06, Florin T.PATRASCU <[email protected]> wrote:
>
> Hi Rebel,
>
> I hear you! I also know many other examples of (un)fortun(at)e 100 companies
> doing weird stuff with Java and architecture, but of course in the name of
> "J2EE and/or enterprise best practices" :)
>
> The classloading story in this case is a JBoss one. Has nothing to do with
> the version of JPublish, I wish it was that easy.
>
> Just curious now, is your application (the EAR) the only web app deployed
> under JBoss? If yes, maybe is not hard to change your legacy code, I don't
> know, and maybe you could refactor that session bean as an MBean and then
> your session, presented as a JBoss service, would be much friendlier to any
> web application deployed. This way, you'll have your (any) application able
> to breath as an unpacked and accessible web ... normal  application :)
>
> I am currently having something similar in production (www.masterfile.com)
> and JPublish is driving a massive web content. It would be impossible to
> administer a site like that if we'll have to pack the dynamic content in
> archives inaccessible to our designers. That will be an unacceptable
> architecture. Anthony and myself as well are big supporters of the
> separation of roles and concerns in the enterprise, as well as in any web
> (non-web) application, that's why JPublish was built the way it is and all
> the merits goes to Anthony in this respect.
>
> Anyway, try to grab the latest libraries from the JP3 trunk and see if there
> is a difference. You could also try to add the groovy-all-1.0-jsr-05.jar to
> your server/all/lib. Mind you the groovy version I have added last night to
> the CVS is compiled with Java 1.5! Also, have you tried to use the
> MANIFEST.MF/Class-Path?
>
>
> -florin
>
> PS
> I discovered recently (a month ago), that JBoss 4.0.4 is better (obvious)
> than the old versions, try it to see how (and if) is changing your
> perspective.
>
>
>
> On 17-Jun-06, at 11:54 PM, Rebel Geek wrote:
>
> Florin,
>
> Getting JP2 may be a solution if the classloading problems are
> resolved. Let me explain a little about our environment:
>
> I work for a fortune 100 (maybe a fortune 10) company run by a very
> large mouse (I dare not give out the name of the company <smile>). We
> have a portal and a SOA environment that provides content to the
> portal. The portal communicates with the SOA environment via WSRP (Web
> Services for Remote Portlet). The infrastructure guys provided us with
> some Ant scripts that will automagically (because our company is built
> on magic <more smiles>) builds a session bean that acts as a web
> service interface to our application. So if I just have a JSP
> accessing a database, the build scripts will "wrap" a web service
> layer around it. This is the reason why I have my WAR file in an EAR.
>
> I have gotten JP3 to work in our version of JBoss 3.2 using the
> following article
>
> http://wiki.jboss.org/wiki/Wiki.jsp?page=ClassLoadingConfiguration
>
> especially the section titled " The Web Container". Though JP3 loads
> and finds bsh it cannot find Groovy for some reason and the action
> only "see" that classes that JBoss loads from the deploy folder or
> what's in the server/all/lib folder of JBoss.
>
> Hope this serves to give somebody in this group an epiphany. Thanks
> all for your help and insight.
>
> Regards,
>
>
> On 6/16/06, Florin T.PATRASCU <[email protected]> wrote:
>
>
>
> On 16-Jun-06, at 12:16 PM, Lateef Jackson wrote:
>
>
> What reasons are you using JPublish for? You may not be loosing
>
> anything but depends on what you like about JPublish.
>
> I subscribe to Lateef's question. If you're not using JP3 in a very specific
> way I may send you a new JP2 (I hope I'll commit it soon to the 2-0 branch
> in the CVS) which is cleaned a bit, some errors are fixed, the access to the
> page components are cached through a pluggable mechanism and all the
> libraries are updated to their latest versions; bsh, groovy, RHINO, etc.
>
> JPublish is a very reliable piece of software (I am biased, of course:) and
> the version I am using (based on 2.0 and I am still working on it) is very
> reliable and efficient, here are my old notes:
> http://weblog.flop.ca/2005/03/12/1110656258000.html, since
> then I added few more changes, such as: groovy support. Currently I am
> working to finalize the DWR support for AJAX and the support for page
> localization based on properties files, a very common i18n specific
> practice.
>
> You can use JP with Spring if you want and from there ... sky's the limit :)
> Here is a small jump-start if you want to try:
> http://www.flop.ca/links/sjp.html
>
> I'll be glad to hear more about your experience.
>
> -florin
>
>
>
> _______________________________________________
> Jpublish-developer mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/jpublish-developer
>
>
>
>
>
>
> --
> Rebel Geek
> [email protected]
> 954-839-6234
>
>
> _______________________________________________
> Jpublish-developer mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/jpublish-developer
>
>
>
> _______________________________________________
> Jpublish-developer mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/jpublish-developer
>
>
>


-- 
Rebel Geek
[email protected]
954-839-6234