Where was I when this Roller announcement was made? Roller Now Simpler to Setup
After finding out today that there is a version of Roller with an embedded HSQLDB database, I went and set it up right away. I did a couple of tricks with it, because I already have a Tomcat server running on port 8080. But after a couple of small script changes, I was up and running in less than 20 minutes total!
I had decided against Roller previously because I didn't want to mess with a separate database just to try it out. This makes things much easier for people to go and give it a whirl.
Wednesday, July 28, 2004
Friday, July 23, 2004
java.net: Using RSS in JSP pages
This is what I've been looking for. A nice example of using a Java API for RSS. Although I wonder if informa is the latest and greatest library to use?
java.net: Using RSS in JSP pages
java.net: Using RSS in JSP pages
Thursday, July 22, 2004
WebLogic Server Administration Best Practices
Great tips and tricks straight from the mouth of BEA (thanks for pointing it out Vinny!):
WebLogic Server Administration Best Practices
WebLogic Server Administration Best Practices
Thursday, July 15, 2004
Yahoo! Mail is making me want GMail more
I used to be happy with Yahoo! Mail, but they have taken away my favorite feature. A few weeks ago when they "upgraded" the interface to compete with GMail, they dropped the "include HTML tags" option when sending an email. It used to be nice that I could write HTML into my email so that my family could see nice pictures without ever needing to attach huge files. I just used a simple img tag that pointed to my website.
So today I'm just frustrated. I've tried multiple different ways, even coding my entire email as HTML, but Yahoo! will not send it as HTML. Does anyone know if GMail will fix my problem? Can I send HTML emails using GMail? I would love to try it out when its available, and I really hope it fixes my problem. Until then, jasheets1 at good ole yahoo dot com will have to suffice as an email address.
So today I'm just frustrated. I've tried multiple different ways, even coding my entire email as HTML, but Yahoo! will not send it as HTML. Does anyone know if GMail will fix my problem? Can I send HTML emails using GMail? I would love to try it out when its available, and I really hope it fixes my problem. Until then, jasheets1 at good ole yahoo dot com will have to suffice as an email address.
Wednesday, July 14, 2004
I agree. IoC appears to replace factories.
Groboclown hits the nail on the head with his discussion about IoC.
Groboclown's Weblog
This is precisely how I view IoC also! I'm just surprised to see someone else explain it in this way. I only wish I was allowed to use IoC in my environment, because each time I do a MyInterface object = new MyInterfaceImpl() I think that using IoC would be so much cleaner.
Groboclown's Weblog
This is precisely how I view IoC also! I'm just surprised to see someone else explain it in this way. I only wish I was allowed to use IoC in my environment, because each time I do a MyInterface object = new MyInterfaceImpl() I think that using IoC would be so much cleaner.
Thursday, July 08, 2004
Is Jess The Best Rules Engine Fit For J2EE?
I'm a little disappointed that no real straight answers came from my last entry: Uncommented Bytes: Jess Architecture in a J2EE Environment
So now I'm lead to believe that Jess may truly be difficult to integrate into our highly scalable, distributed, enterprise architecture. Wrapping Jess in a custom RMI server doesn't seem very elegant to me, but as of now it looks like the only solution. As I mentioned in the comments of my other post, if Jess is the reference implementation for JSR 94, wouldn't they come up with a better way to integrate into a J2EE environment?
So now I'm lead to believe that Jess may truly be difficult to integrate into our highly scalable, distributed, enterprise architecture. Wrapping Jess in a custom RMI server doesn't seem very elegant to me, but as of now it looks like the only solution. As I mentioned in the comments of my other post, if Jess is the reference implementation for JSR 94, wouldn't they come up with a better way to integrate into a J2EE environment?
Wednesday, July 07, 2004
Jess Architecture in a J2EE Environment
We need to implement the Jess rules engine into a clusterable distributed environment. The question lies in how Jess is deployed.
It would appear that it cannot be deployed inside of an App Server because Jess does it's own threading. After some research into JSR 94 (Rules engine API/SPI) it is still unclear how Jess would actually run in our environment. I seem to remember that Clipse ran as a single server instance and that our EJB's across the cluster would access this single instance. I also believe that Jess would have to run in this way, as a single server, however Jess itself is not a server.
So how does an EJB in a cluster access the single instance of Jess? Do we write an RMI server to wrap the Jess instance (as suggested in "Jess in Action"), or do we some how use JCA to connect each App Server to Jess?
So far we've written the RMI wrapper, but it seems like this could be easier.
It would appear that it cannot be deployed inside of an App Server because Jess does it's own threading. After some research into JSR 94 (Rules engine API/SPI) it is still unclear how Jess would actually run in our environment. I seem to remember that Clipse ran as a single server instance and that our EJB's across the cluster would access this single instance. I also believe that Jess would have to run in this way, as a single server, however Jess itself is not a server.
So how does an EJB in a cluster access the single instance of Jess? Do we write an RMI server to wrap the Jess instance (as suggested in "Jess in Action"), or do we some how use JCA to connect each App Server to Jess?
So far we've written the RMI wrapper, but it seems like this could be easier.
Eclipse Rises
As I mentioned previously, I was having trouble with the 3.0 release of Eclipse. I thought it was time for an update, as my opinion has improved dramatically.
As a quick background, I have been using Eclipse since early 2003 when I fell in love with it. Eclipse made my life so much easier. I had been longing for an IDE that could refactor, even though I didn't know what to call it. I couldn't understand why imports couldn't be automatic, and compiling couldn't be simpler. Code completion was nice, but I wanted more, and Eclipse delivered.
3.0 was causing me grief in the speed department. However after using it for about a week of actual work I'm not seeing the speed hit anymore on my Windows 2K machine***. I'm loving the Ant integration that finally works for me. Until now I always used Ant externally as the embedded version failed. I did have to point to a 1.5.4 version of Ant since 1.6.x seems to cause problems with a few Weblogic specific tasks (that are poorly written, I might add). I'm getting used to code folding, a feature I didn't think I would use. The "add/remove block comment" option is nice. And JUnit testing seems smoother for some reason. Add with the CVS enhancements and color scheme improvements, and I'm a happy camper!
*** - I do see occasionally a long pause after not using Eclipse for many minutes. Maybe someone has seen a bug report on this?
As a quick background, I have been using Eclipse since early 2003 when I fell in love with it. Eclipse made my life so much easier. I had been longing for an IDE that could refactor, even though I didn't know what to call it. I couldn't understand why imports couldn't be automatic, and compiling couldn't be simpler. Code completion was nice, but I wanted more, and Eclipse delivered.
3.0 was causing me grief in the speed department. However after using it for about a week of actual work I'm not seeing the speed hit anymore on my Windows 2K machine***. I'm loving the Ant integration that finally works for me. Until now I always used Ant externally as the embedded version failed. I did have to point to a 1.5.4 version of Ant since 1.6.x seems to cause problems with a few Weblogic specific tasks (that are poorly written, I might add). I'm getting used to code folding, a feature I didn't think I would use. The "add/remove block comment" option is nice. And JUnit testing seems smoother for some reason. Add with the CVS enhancements and color scheme improvements, and I'm a happy camper!
*** - I do see occasionally a long pause after not using Eclipse for many minutes. Maybe someone has seen a bug report on this?
Tuesday, July 06, 2004
Open Source Portals and Apache Jetspeed Update
A couple of updates from my Commentary on Jetspeed.
First, I was thrilled to see Benjamin of the eXo team respond to my remarks, and also receive great feedback from Stéphane regarding Jahia. Second, my eyes bugged out reviewing my hit counts at bstats (for Blogger users) and seeing that I had been on the front page of TheServerSide.com (sincere thanks to Dion)!
Benjamin mentioned in my comments here, on Punit's blog, and at TheServerSide, that Punit valued JSR 168 highly in his list. My list was merely my opinion, and in no way a challenge to Punit. I was simply trying to add another person's input into the community. I hope that it didn't seem that I was attacking his list, because I was trying to just share my thoughts. This is why at the end of my post I pointed out:
And Stéphane, I believe from my testing that Jahia is a great product, however Jetspeed 1 is all that we needed. I too look forward to using Jetspeed 2 when it is released!
So my list stands with Jetspeed in the lead. It will take a great portal to knock it from my list, and as such I hope to evaluate eXo, Jahia, and the others, again in the future. However at this time it is still true that Jetspeed 1.x is the only open source portal that I will trust in our production environment.
First, I was thrilled to see Benjamin of the eXo team respond to my remarks, and also receive great feedback from Stéphane regarding Jahia. Second, my eyes bugged out reviewing my hit counts at bstats (for Blogger users) and seeing that I had been on the front page of TheServerSide.com (sincere thanks to Dion)!
Benjamin mentioned in my comments here, on Punit's blog, and at TheServerSide, that Punit valued JSR 168 highly in his list. My list was merely my opinion, and in no way a challenge to Punit. I was simply trying to add another person's input into the community. I hope that it didn't seem that I was attacking his list, because I was trying to just share my thoughts. This is why at the end of my post I pointed out:
I should do another entry on JSR 168 and why that is not important to us, yet. Jetspeed essentially shelters us from the current hype.And I still intend to do this. In a nutshell, Jetspeed allows us to write actions and jsp's using their built-in MVC Portlet and thus not have to write portlets of our own (thus making JSR 168 negligible). Using Jetspeed as an "Application Portal" and not as an "Enterprise Portal" allows leverage for us that others are unable to achieve.
And Stéphane, I believe from my testing that Jahia is a great product, however Jetspeed 1 is all that we needed. I too look forward to using Jetspeed 2 when it is released!
So my list stands with Jetspeed in the lead. It will take a great portal to knock it from my list, and as such I hope to evaluate eXo, Jahia, and the others, again in the future. However at this time it is still true that Jetspeed 1.x is the only open source portal that I will trust in our production environment.
Thursday, July 01, 2004
Proxy Breaks Weblogic Web Service Testing
A peculiar error came up while trying to test my weblogic web service. BEA provides a test page for web services that you can use in development. So I went to the page to test my ProofOfConceptService (brilliant name, huh?). I received this error:
Immediately I keyed in on the "403: Forbidden". So how can I be forbidden to access my localhost? After cruising google and bea newsgroups I only found 1 mention of this and 0 fixes. Then I thought of the line I added to my startup script that adds our proxy configuration to the JVM:
This allows our Jetspeed portal to pull in web feeds through our firewall. Turns out that when I removed this the test went fine. It appears the JVM attempts to use the proxy even when I'm accessing the localhost. I guess there's no way around this than to remove the proxy setup line everytime I want to test a local web service. Unless someone knows of a way to tell a JVM to ignore a proxy for certain hosts?
weblogic.webservice.tools.wsdlp.WSDLParseException: Failed to retrieve WSDL from http://localhost:80/jetspeed/ProofOfConceptService?WSDL. Please check the URL and make sure that it is a valid XML file [java.io.FileNotFoundException: Response: '403: Forbidden' for url: 'http://localhost:80/jetspeed/ProofOfConceptService?WSDL'] at weblogic.webservice.tools.wsdlp.DefinitionFactory.createDefinition(DefinitionFactory.java:126) at weblogic.webservice.tools.wsdlp.WSDLParser.(WSDLParser.java:76) at weblogic.webservice.WebServiceFactory.createFromWSDL(WebServiceFactory.java:108) at weblogic.webservice.WebServiceFactory.createFromWSDL(WebServiceFactory.java:84) at weblogic.webservice.server.servlet.ServletBase.invokeOperation(ServletBase.java:295) at weblogic.webservice.server.servlet.WebServiceServlet.invokeOperation(WebServiceServlet.java:344) at weblogic.webservice.server.servlet.ServletBase.handleGet(ServletBase.java:266) at weblogic.webservice.server.servlet.ServletBase.doGet(ServletBase.java:158) at weblogic.webservice.server.servlet.WebServiceServlet.doGet(WebServiceServlet.java:255) at javax.servlet.http.HttpServlet.service(HttpServlet.java:740) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.java:971) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:402) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:305) at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:6350) at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:317) at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:118) at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:3635) at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2585) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170)
Immediately I keyed in on the "403: Forbidden". So how can I be forbidden to access my localhost? After cruising google and bea newsgroups I only found 1 mention of this and 0 fixes. Then I thought of the line I added to my startup script that adds our proxy configuration to the JVM:
-DproxySet=true -DproxyHost=ourproxy.server.com -DproxyPort=80
This allows our Jetspeed portal to pull in web feeds through our firewall. Turns out that when I removed this the test went fine. It appears the JVM attempts to use the proxy even when I'm accessing the localhost. I guess there's no way around this than to remove the proxy setup line everytime I want to test a local web service. Unless someone knows of a way to tell a JVM to ignore a proxy for certain hosts?
Which Portal? Apache Jetspeed, of course!
Punit asked Which Open Source Portal Server?, and here is my answer:
He lists the top contenders in the open source portal market as:
eXo
Gridsphere
uPortal
Apache Jakarta Jetspeed 2
Liferay
I would mod it to change Jetspeed to version 1 and add Jahia.
About 5 months ago I did a fairly extensive evaluation of the portal market. I chose Apache Jetspeed 1. We are running 1.4 now, but are migrating to 1.5 soon and 2.0 when it is finally released. We are so happy with Jetspeed! At the time of my evaluation it was miles ahead of Liferay, eXo, and uPortal for our purposes.
eXo looks promising, but is/was still in its infancy. uPortal is great for universities, but we need an application portal not an enterprise/university portal. We don't need email/calendar/todo lists. What we need is a framework so our applications can utilize portlets for extensibility and customization. Liferay looked like it needed a new architecture regarding JSR 168.
For us it came down to Jahia and Jetspeed. Jahia is a very nicely done portal that runs on the Jetspeed platform. However I had problems running it in Weblogic. Also Jetspeed was more customizable for our purposes. It handles customization of data and user views. It is very easy to get running and very easy to program for. We use a blend of Jetspeed MVC and Struts for our architecture components. We have been able to extend sections of the Jetspeed code for our purposes too! The Apache Jakarta name is a huge seller in our government environment, and this went a long way in helping me sell the portal above Weblogic's Portal, TIBCO, Plumtree, and Vignette.
Jetspeed 2 looks to be great when it is stable and released. Until then, Jetspeed 1 is all we need. I should do another entry on JSR 168 and why that is not important to us, yet. Jetspeed essentially shelters us from the current hype.
[Update: 12/21/2004] I would now upgrade this to say, pick Jetspeed 1.6 Fusion if you want JSR-168 portlets when migrating from the original Jetspeed. In this way, we can still support our original Jetspeed portlets until they are fully migrated to JSR-168 versions. I would also choose Jetspeed 1.6 Fusion for a new project, but only develop JSR-168 Portlets for it. This way you can easily migrate to Jetspeed 2 when it is final and stable. Take a look at the struts portal bridge, that can be deployed on any portal to use struts in developing your portal apps.
[Update: 2/20/2006] Wow, I'm impressed that people are still hitting this page quite regularly! Some of you may also be interested in my thread related directly to deploying Jetspeed on Weblogic: Jetspeed on Weblogic FAQ
He lists the top contenders in the open source portal market as:
eXo
Gridsphere
uPortal
Apache Jakarta Jetspeed 2
Liferay
I would mod it to change Jetspeed to version 1 and add Jahia.
About 5 months ago I did a fairly extensive evaluation of the portal market. I chose Apache Jetspeed 1. We are running 1.4 now, but are migrating to 1.5 soon and 2.0 when it is finally released. We are so happy with Jetspeed! At the time of my evaluation it was miles ahead of Liferay, eXo, and uPortal for our purposes.
eXo looks promising, but is/was still in its infancy. uPortal is great for universities, but we need an application portal not an enterprise/university portal. We don't need email/calendar/todo lists. What we need is a framework so our applications can utilize portlets for extensibility and customization. Liferay looked like it needed a new architecture regarding JSR 168.
For us it came down to Jahia and Jetspeed. Jahia is a very nicely done portal that runs on the Jetspeed platform. However I had problems running it in Weblogic. Also Jetspeed was more customizable for our purposes. It handles customization of data and user views. It is very easy to get running and very easy to program for. We use a blend of Jetspeed MVC and Struts for our architecture components. We have been able to extend sections of the Jetspeed code for our purposes too! The Apache Jakarta name is a huge seller in our government environment, and this went a long way in helping me sell the portal above Weblogic's Portal, TIBCO, Plumtree, and Vignette.
Jetspeed 2 looks to be great when it is stable and released. Until then, Jetspeed 1 is all we need. I should do another entry on JSR 168 and why that is not important to us, yet. Jetspeed essentially shelters us from the current hype.
[Update: 12/21/2004] I would now upgrade this to say, pick Jetspeed 1.6 Fusion if you want JSR-168 portlets when migrating from the original Jetspeed. In this way, we can still support our original Jetspeed portlets until they are fully migrated to JSR-168 versions. I would also choose Jetspeed 1.6 Fusion for a new project, but only develop JSR-168 Portlets for it. This way you can easily migrate to Jetspeed 2 when it is final and stable. Take a look at the struts portal bridge, that can be deployed on any portal to use struts in developing your portal apps.
[Update: 2/20/2006] Wow, I'm impressed that people are still hitting this page quite regularly! Some of you may also be interested in my thread related directly to deploying Jetspeed on Weblogic: Jetspeed on Weblogic FAQ
Subscribe to:
Posts (Atom)