What Would You Expect in a Lightweight Admin Console for Weblogic

Discussions

News: What Would You Expect in a Lightweight Admin Console for Weblogic

  1. With every release, Weblogic server gets faster, but its Admin Console on the other hand gets slower. The current version of console is very slow and consumes a lot of memory. At Cypal, we are working on an admin console for weblogic called "Cypal Lite", which will be a light weight alternative to the standard console. While the standard console gives you options to do everything, Cypal Lite will provide you only the most frequent operations (like creating a JDBC Data store, view the logs, deploy an app, ...) We would like to get feedback from the community on the usage of the Admin Console. What is the operation that you perform very frequently? Visit: www.cypal.in/lite for more info

    Threaded Messages (40)

  2. The new WebLogic console is based on the BEA portal, and is certainly not user friendly, however if you do repeatedly the same tasks then you should use WLST scripts to automate them.
  3. Where do I get it?[ Go to top ]

    Is there a version of this "lite" console available for download? Satya Ghattu
  4. Re: Where do I get it?[ Go to top ]

    Is there a version of this "lite" console available for download?
    Not yet. We are still working on a Tech Preview version, which should be available soon. Visit Cypal Lite page for more info.
  5. The console will be faster and more responsive starting with WLS 10.3 (currently in Tech Preview). The lead developer has blogged about that here: http://dev2dev.bea.com/blog/jsnyders/archive/2007/11/wls_console_beauty_more_than_s.html
  6. We read that blog entry. I bet our pages are much more lighter the standard console. Our console is written with Google Web Toolkit. So we get all its advantages (including CSS sprites) and the generated JavaScript is smaller than any hand-coded one. You don't need any tools/techniques to measure the difference in speed, you would simply "feel" it when using Cypal Lite.
  7. The latest / soon to be released console is faster. I would additionally like to point out that while the base console is a one-stop shop for configuration, monitoring, etc. The console is extensible as well(i.e. console extensions http://e-docs.bea.com/wls/docs100/console_ext/understandext.html ) to the point that you can provide a more pruned set of capabilities for common tasks, without resorting writing another console. Additionally if the extension is deployed as a new desktop (portal term) then it would be faster as well. Perhaps you would consider releasing this as a console extension?
  8. You guys should create a console for JBoss.
  9. You guys should create a console for JBoss.
    I agree, that would be awesome.
  10. You guys should create a console for JBoss.


    I agree, that would be awesome.
    May be *after* we release Cypal Lite :-)
  11. Perhaps you would consider releasing this as a console extension?
    We are not extending the functionality of the existing console, rather trying to replace the console for frequently used operations, so that you can perform things faster. Making this as an extension is not an option for us :-)
  12. Perhaps you would consider releasing this as a console extension?


    We are not extending the functionality of the existing console, rather trying to replace the console for frequently used operations, so that you can perform things faster.

    Making this as an extension is not an option for us :-)
    I'm not suggesting you replace functionality, but rather providing a plugin (i.e. an extension) which collects frequently used operations into one place. ;)
  13. I'm not suggesting you replace functionality, but rather providing a plugin (i.e. an extension) which collects frequently used operations into one place. ;)
    What you are asking for is just bookmarking facility. But that doesn't improve the speed of the operation! + there are other features like wizard framework or undo/redo can't be done with the existing console - not even as an extension
  14. Business Expectations: I never needed to go for advanced options. Technical Expectations: Do not use applets. Do use Ajax on click of particular option.
  15. Do not use applets.
    Do use Ajax on click of particular option.
    No Applets, and the console is entirely Ajax
  16. No Applets, and the console is entirely Ajax
    I am not sure at all that having Ajax all over the place makes things faster. For example if I have gmail page open in my browser then it takes around 12 units of CPU time in the ActivityMonitor and when I see similar UI implemented in Flex(Flash) then the browser consumes around 5 units of CPU time. And in general complex Ajax UIs do not feel faster to me. It seems like JavaScript virtual machine is the slowest of all VMs available on client: Java VM, Flash VM, SilverLight VM, and JS VM.
  17. No Applets, and the console is entirely Ajax
    I am not sure at all that having Ajax all over the place makes things faster. For example if I have gmail page open in my browser then it takes around 12 units of CPU time in the ActivityMonitor and when I see similar UI implemented in Flex(Flash) then the browser consumes around 5 units of CPU time.
    The initial loading time will be a little longer, but after that everything should be much faster than the normal JSP pages
  18. Applet was faster than the Ajax[ Go to top ]

    Do not use applets.
    Do use Ajax on click of particular option.


    No Applets, and the console is entirely Ajax
    Actually the version with the Applet and no Ajax was the fastest and cleanest. When they went to 9.0 and removed the applet it became much harder to navigate. Now everything is so many mouse clicks down it is tedious.
  19. I don't use Weblogic, at least not recently. I happen to like the console in Glassfish, I think they've done a pretty good job. But here's my comments on a "lightweight" console. First thing, whatever aspects you choose to support -- it has to support them fully. For example, if you choose JDBC pools and what not, don't leave any options off. You can put them on an advanced tab, you can tune the UI so the common stuff is easy, but you can't remove options. When you remove options, then at some point the tool becomes absolutely useless, because someone will need that option and it won't be there. What is "rare and edge case" to one person, is day to day management to another. There are certainly more of the prior than latter people, but just be conscious that these latter folks won't use the tool at all. Few things as aggravating as bouncing between tools that ostensibly do the same thing. Save for log files, I'd remove any monitoring aspects from the console. When a deploy goes bad, you'll want log files to be able to find out what went wrong. But I'd dump all of the other monitoring. Let something else do that. Focus on configuration and deployment. If you can tweak deployment artifacts on the fly, that would be an amazing feature. Sometimes folks need to "crack the EAR/WAR" to get to a descriptor. If the Console can do that prior to deployment, I think that would be a great feature.
  20. If you can tweak deployment artifacts on the fly, that would be an amazing feature
    More amazing is that you can already do it today using a deployment plan.
  21. If you can tweak deployment artifacts on the fly, that would be an amazing feature


    More amazing is that you can already do it today using a deployment plan.
    GlassFish has deployment plans, but you can't create or modify one through the console, it's not a casual things. I don't know if WLS can do this from the console or not. But I was, even then, consider something more casual. Just being able to open up and edit the XMLs from the deployment screen would be useful.
  22. But I was, even then, consider something more casual. Just being able to open up and edit the XMLs from the deployment screen would be useful.
    That's something I would vote for. Frankly, We have been using direct XML editing for WLS config for years. And we rarely use console. All the fancy tools WLST and admin console are no match for the simplicity and advantage of direct XML editing. We usually use Admin Console to generate the "Template config files" such as config.xml, jdbc/_DS.xml and jms/.xml. Similarly, you will need to use admin console to figure out the application deploy XML segment and debugging segment etc. Once these files are created, then you can forget about the admin console or WLST tools. Save these template xml files, and you can automated your deployment by replacing the deployment, database jdbc url; jms, turn on/off certain element (such as foreign jms) using ANT scritps. The best part of this approach is that all these are done OFF-LINE. All you need to do to copy these XML files to the proper location and start Weblogic. Compare to Admin Console or WLST approach, you have to turn on the weblogic; wait for it started, then login to the UI and find the proper page and do you thing. For example, to turn on the JPA JDBC debugging, beside have to wait for BEA weblogic to start and Admin Console show up, you have to drill down from all the page to the proper element and click and save. But all these actions are only translated into 3 lines of XML element in config.xml Even WLST is a bit slow and on top of you need to write python scripts. There are cases this approach doesn't work. For those I turn to WLST scripting. In particular, when trying to add a user (role) in Security Realm, the information is probably stored in an Embedded LDAP somewhere and is not exposed via XML configuration, I have to write a python script and keep ping weblogic to see if it started; once it started, I run the addUser.py WLST script to add the desired users.
  23. Ya know, back in the day, I was exactly that way with Weblogic. Just how it was. Always hacking the XML file. But for whatever reason, when we moved to Glassfish, we simply don't do that anymore. We fire up the server, and use the console. Maybe it's because the console is pretty good. I'm not going to compare against WLS, or say there's is better or worse, that's the not that point. Just that GFs is nice enough that using it for this stuff, which happens occasionally, is quick and good enough for what we do. If I were rolling out dozens of instances, then, yeah, we'd be hacking XML files -- it would be insane not too. All I can say is that the console is painless enough that I haven't been compelled to hack the XML files, even tho it too would be "3 lines of XML". Same with deploys to the remote server. I SHOULD have a little script using asadmin to deploy my apps, but deploying through the console hasn't been bad enough to prompt me to go through that effort of writing and testing a deploy script. It's just a way of working.
  24. I guess this depends what you used for. For us, there are three types of use cases: 1) Developers who do the daily development. 2) Nightly automated installation and tests. 3) QA and Client Installation Tools. For case 1), use Admin Console might be OK, if it fast enough, once the procedure is stabled enough, you publish the procedures for every one to following, do step 1, 2, 3. Then you are done. continue to work (deploy or redeploy, rebuild database etc). But even in this case, use Console is not as convenient. For example, if one developer add a new feature and requires a JMS topic, he goes ahead to his console, and check in the code, then he has to tell every one to do the same and described the details of the changes. If you have a XML config, the developer simply changes the config XML and check in. He still needs to communicate that the configuration has been changed. All other developers need to do is to update the new config xml from CVS and call ant setup-domain (that's our target name). For use case 2, nightly automated testing, Admin Console is out of quesiton and can't be used. You either hack the XML or writing the python scripts. Considering we use Ant to do the build, using XML to manipulate different test/QA/stage environments is much easier (considering there are different set of hosts, databases, and configurations). For use case 3, may be it is just me, I would consider it not user-friendly if you have ask client to launch the Admin Console to configure the application. For me, I would give client an installation zip (or tar) file, they unzip it, edit a few properties (ports, hosts, directories etc.) and then type ./setup.sh or ./install.sh or ant install. After that the application is configured, the weblogic is started and ready to use. Consider all these use cases, hacking XML is the best way to go for all. I will be very disappointed if BEA change that.
  25. I would be careful in putting too much code around manipulating the config XML's. Did you consider how much work it would be to upgrade all your ANT scripts if BEA changes the schema of their config.xml in their next version? I would stick to WLST scripts, they are guaranteed to work for atleast two major versions. My 2 cents Satya Ghattu
  26. I would be careful in putting too much code around manipulating the config XML's. Did you consider how much work it would be to upgrade all your ANT scripts if BEA changes the schema of their config.xml in their next version?

    I would stick to WLST scripts, they are guaranteed to work for atleast two major versions.

    My 2 cents

    Satya Ghattu
    I know it is non-standard way of doing configuration. But so far we are in luck for Version 6.0, 8.1,9.x, 10.0 and 10.3tp. It sure lasting longer than WLST. Of course, you might have to change the configuration template a bit if BEA changes the schema and structure (like /application to /autodeploy; change JDBC configuration to /jdbc etc.), but you only do it once and check them in. With Ant, this is so easy to do, it probably take an developer 1-2 days to make changes and verifies it works. it is not a big deal even BEA changes the schema every 2 years. WLST is only come along in WLS 9.0 (my memory could be incorrect) and it requires you to start weblogic first before you do anything. This reminds me the IBM Websphere's way of doing thing, which I really don't like: In order to configure something, start the server, configure them, and then shut it down; and you have to wait for long time for doing so. I prefer OFF-LINE configuration, if I can, of course.
  27. Well thought points. Thanks Will.
  28. Leveraging PF in 9 represented one of the most significant components of the Console app allowing the Console to be a lot more flexible. This also caused the Console to take some performance hits and we heard the outcry from the field loud and clear. The team has made significant performance improvements in the most recent version of the WebLogic Server 10.3 Admin Console and we will continue to investigate and move on that path. The main work in performance has focused on Login Display, Page Nav and Memory consumption. Although it is difficult to meet the needs of small, medium and large customers being that the Console is leveraged differently in these many environments, I’ve heard some interesting feedback, ideas and thoughts in this thread and certainly encourage you to continue. It is key to obtain this knowledge from our users and investigate how we continue to make the Console better and incorporate your feedback back into the product. Cheers, Sabrina M. Reynoso WLS Sr. Product Manager - Oracle
  29. Sabrina Thank you for your response on this thread. And I really appreciate you are listening to the user's feedback. I know the discussion is off topic from the original thread. But .. There is one more thing which I wish All Application Sever do (in particular, Weblogic Server, may be it already does it, I just don't know): that is to expose a Event Interface allow us to know when the Application Server is fully started and when client application is fully deployed. So we can plugging our additional scripts/codes. For example, using WLST to add user to Weblogic, we will need to wait weblogic started first before calling the WLST script. In an automated environment, no one is watch the console to see if the weblogic is ready or not. So far we are pinging weblogic by doing a wget on http://localhost:7001/console url to see if it gets 200 OK. I know, very basic. I wish there is a way weblogic simply tells me (callback, or status, or ping interface, etc.) when weblogic is ready so the addUser script won't fail. The second part of the wish (indicating when application is fully deployed/started) may be EJB question, but I like to see weblogic can provide something before the standards come out. Similarly, there are bootstrap codes need to be run before user can use it. But bootstrap codes must be run after the application is fully deployed. If we can have a way of indicating that the application is ready that would be great. Right now, we wrote a ping interface, and pinging our application. If it not fully deployed, it will fail; but even it is fully deployed, the application may not be ready as Weblogic 10.3tp will deployed it twice, one from cache and another one real location. so we have to wait for few seconds and ping it again until it sends back the response. If you can do something about this, that would be great. Double deployment issues is a separate issue. Chester
  30. know when the Application Server is fully started and when client application is fully deployed.
    you can listen to SNMP traps, or use the diagnostic framework.
    we will need to wait weblogic started first before calling the WLST script. In an automated environment, no one is watch the console to see if the weblogic is ready or not.
    you can add some sleep to your WLST script with a periodic polling for the server status before starting your script. you can also start your server using wlst...
    The second part of the wish (indicating when application is fully deployed/started) may be EJB question, but I like to see weblogic can provide something before the standards come out. Similarly, there are bootstrap codes need to be run before user can use it. But bootstrap codes must be run after the application is fully deployed. If we can have a way of indicating that the application is ready that would be great.
    this is called ApplicationLifecycleListener
  31. Thanks for your response.
    know when the Application Server is fully started and when client application is fully deployed.


    you can listen to SNMP traps, or use the diagnostic framework.

    I haven't done this before with weblogic and if you can point out some samples or documents that would be helpful. I will also check with weblogic documentations.
    we will need to wait weblogic started first before calling the WLST script. In an automated environment, no one is watch the console to see if the weblogic is ready or not.
    you can add some sleep to your WLST script with a periodic polling for the server status before starting your script.
    That what we did now, we pinging script except it is not WLST script, but simply shell script. And the Server status is indirectly from the Admin Console. I wish Weblogic has native pinging interface, or call back interface, so I don't need to the polling.
    you can also start your server using wlst...
    What's the benefit of using WLST to start the server instead of using Shell Scripts ? We have to extend the script with additional JAVA Options, class path etc.
    The second part of the wish (indicating when application is fully deployed/started) may be EJB question, but I like to see weblogic can provide something before the standards come out. Similarly, there are bootstrap codes need to be run before user can use it. But bootstrap codes must be run after the application is fully deployed. If we can have a way of indicating that the application is ready that would be great.
    this is called ApplicationLifecycleListener
    I haven't use that, I will check on that. Thanks.
  32. What's the benefit of using WLST to start the server instead of using Shell Scripts ? We have to extend the script with additional JAVA Options, class path etc.
    You do not have to throw away your start weblogic script, you can invoke the script from WLST, please see my blog entry. I am really not proposing you to change how you are building your environment, but you could benefit from using these new tools introduced from 9.x that may save you a lot of time now and in the future. Satya Ghattu

  33. What's the benefit of using WLST to start the server instead of using Shell Scripts ? We have to extend the script with additional JAVA Options, class path etc.


    You do not have to throw away your start weblogic script, you can invoke the script from WLST, please see my blog entry.
    Thank you for you response, and I like to keep my mind open and welcome the advice from experts. I read your blog,may be I missed something, but it doesn't explain what's the benefit pf using WLST to start Weblogic comparing simply using the shell script. It seems focus on the shorts comings of WLST startServer() command and how to overcome it by using WLST to invoke a shell script directly.


    I am really not proposing you to change how you are building your environment, but you could benefit from using these new tools introduced from 9.x that may save you a lot of time now and in the future.

    Satya Ghattu
    I will certain keep my mind open to the new tools and see how it can improve our process. Thank you.
  34. Since 10.0 WLS Console can automatically create WLST scripts as users are performing actions on the console. See http://edocs.bea.com/wls/docs100/ConsoleHelp/taskhelp/console/RecordWLSTScripts.html With above, I've seen users quickly pickup WLST and automate their most commonly used tasks. For more involved tasks I use WLS console, but for simpler tasks I use WlNav (https://wlnav.projects.dev2dev.bea.com/) , especially when I know what I want to modify in the MBean tree (as exposed in WLST). Since I'm one of the creator of WLNav my opinions are biased, but i've found that between WLS Console, WLNav and WLST all my configuration and monitoring needs are met. --Vishal P.S: I've wanted to port WLNav to use GWT for a while but never had the time.
  35. For example, using WLST to add user to Weblogic, we will need to wait weblogic started first before calling the WLST script. In an automated environment, no one is watch the console to see if the weblogic is ready or not.
    You can use offline WLST to do this. You can configure an entire domain and also update an existing domain with out starting the server, check this. There are a number of code samples posted here. Also checkout an excellent article about using offline wlst, here. Satya Ghattu
  36. we heard the outcry from the field loud and clear. The team has made significant performance improvements in the most recent version of the WebLogic Server 10.3 Admin Console and we will continue to investigate and move on that path
    Sabrina, I've been using Weblogic since 6.* and a great fan of it. But when it comes to console, its otherwise. With every release, its been a pain to work with. To make things worse, you can't get beyond the login page in 10.* on a Mac (and I'm on a 17" MacBook Pro with 2 GB memory) And thats one of the reasons we started this product. Our Cypal Lite is purely light weight console and it can load on my 4 yr old P4 desktop PC with 512 MB memory. Its not that the memory consumption is the only issue with the current console. It would take several clicks and multiple page loads to accomplish common tasks such as deploying an application. We have thoughtfully designed the interface to address this as well.
  37. Great that somebody of BEA is listening here! I find the confirmation pages and "lock and edit" quite annoying and time consuming, but I understand that they are important for a production system. But for the zillions of servers running on developers' PCs these confirmations should be off. developmentMode=true should imply that there are no confirmations and no locks. Thanks, Juergen
  38. I find the confirmation pages and "lock and edit" quite annoying and time consuming, but I understand that they are important for a production system.
    Juergen, Cypal Lite already gets rid of them :-)
  39. Mail when released[ Go to top ]

    Hi there, I have looked at the web site but I couldn't find the service whereas I can write my email so that I can be notified when the release happens Would you mind providing this service? Regards, Christos
  40. Re: Mail when released[ Go to top ]

    Hi there,

    I have looked at the web site but I couldn't find the service whereas I can write my email so that I can be notified when the release happens

    Would you mind providing this service?
    We had the information in the page. You just need to send a mail to lite at cypal dot in Thanks for pointing out, I've reorganized the contents in the page
  41. Updates in blog[ Go to top ]

    Our team will be posting the updates in our blog: http://blog.cypal.in If you are interested, please subscribe to the blog