> Hi,
>
> Here is my 2 cents to the features I'd like to see in
> GlassFish:
>
> - Better Web-front-end: Like a few others have said,
> I'd prefer to have the web-front-end do more to spare
> me the need to install apache beside it. The
> integration of the load balancer would then be much
> easier. I also would like to have an integrated
> reverse proxy to hide the complexity of my server
> instances behind an omogenous screen name.
>
Interesting. Both you and Will have a similar thought. Can you ( or will) give a more specific use cases? Example: GlassFish V3 in the web tier as a web server also reverse proxying to GlassFish V3 instances running business logic? Example2: All-in-one web server / app server to simplify certain deployments. Are these accurate? Can you provide others?
> - Better provider help: Being able to create a plan
> jar for a given EAR or WAR (sometimes, we get it
> without bindings and extensions and don't have the
> right to change the artifacts) would be helpfull.
> Change of the bindings in the admin console.
I'm having a hard time parsing this. Can you be more descriptive with an example?
> Application versioning (also mentioned before) for a
> fallback scenario.
>
That's roughly 4 or 5 from my count on application versioning. Most popular request so far.
> - Different admin Roles: Also mentioned before. I'd
> like a "read only" user, a user that can only
> stop/start servers and one that can do everything but
> change the configurations (beside the admin of
> course).
>
Yep, this is *going* to happen. Roles-based access control.
> - Intelligent Servers: I know this one is a big step,
> but I think it would be really helpfull and something
> I haven't seen around (IBM is trying, but it's not
> really working all that well). I would like to define
> a dynamic plattform as a set of node agents and some
> runtime rules. This will create a cluster with a
> defined number of instances (defined in the rules as
> the minimum). The system will have a feedback
> mechanism that, based on the rules, will create or
> destroy instances and install the application on them
> at run time to allow peaks to be dynamically handled
> (by having more servers online) and unneeded
> resources saved (by removing or stopping the
> servers). Of course, some kind of monitoring
> functions should be implemented to watch over the
> system.
Self-management is a start:
https://glassfish.dev.java.net/javaee5/selfmanagement/selfmanagementhome.html. Not a simple problem. Thanks for the feedback.
>
> - Singelton Service: I haven't found out if the HA
> Manager can do that or not, but I would like to
> defines Services (timers, batches, applications) that
> are running on exactly one server at a time (this is
> very usefull for pub/sub applications where you only
> want one MDB to catch the message and process it and
> can't have a point to point because your JEE apps is
> not the only one listening in). The problem of having
> only one instance is that it cannot run as a 24/7
> service (Single Point Of Failure) and the HA Manager
> should be able to "take it under it's wing" and
> control that, if the server instance it is running on
> is down, a new server instance is started. That way,
> you could create High available singelton services.
>
Noted.
> - Component Installation: If some of the things
> spoken about in the Forums and Feature request are
> implemented in GlassFish v3, the whole thing will get
> a lot bigger and more complex. As not everyone will
> want to use everything (we are currently not using
> the JBI part, that will come later) I would like the
> installation to be more component based. There should
> be a new profile "expert" where you can define which
> component to install and which should not be. By that
> I don't mean it should be removed if it is used
> internally (like the JMS component) but that the
> administrator shouldn't be able to configure it and
> an application shouldn't be able to be deployed if it
> needs a component that is not installed. This would
> make the GFv3 instances more managable (and won't
> require a very expensive group of expert to do the
> runtime part, only the engineering part).
>
This is good feedback. Is this primarily for the developer role? My initial thought is to download a small (web tier bundle) and use the update center to download the additional components. Is that sufficient?
> That's about it :D
> greets
> jeremie
Great feedback, jeremie. Thanks!
[Message sent by forum member 'jclingan' (jclingan)]
http://forums.java.net/jive/thread.jspa?messageID=243979