> > 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?
>
Reverse Proxy: This functionality is to hide the complexity of my GF installation to the outside world. Here a scenario: I have a cluster of 2 Instances on 2 different nodes running application 1 and 3 single instances running the application 2 (not clustered) for load purposes. If I want the applications to be seen under one name (
http://server.mycompany.com/app1,
http://server.mycompany.com/app2), I need a reverse proxy to do it for the single instances and/or a webserver for the cluster (menu point load balancer). I would like this funktionality to be in the application server itself.
Some other features of a web server I'd like implemented: "default Error Pages", URL redirect, Document root (for static content referencing).
Your first example is more in the line of Component installation than the actual functionality. more on that further down.
> > - 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?
>
Okay. The scenario is like this: We have multiple level in our company
- Test is for Quality checks and usability checks
- Integration is for load testing, user acceptance and general integration with legacy systems
- Production is well... prod :D
The Test platform has a lot of engineering and quality assurance guys (JEE experts), the Integration a lot less and the Production more or less none (don't ask me why, I didn't design the organisation).
Someone (could be from an in-house group or an external firm from an outsourced project) gives us some artifact (ears, wars, rars) to be deployed.
Some of them can be opened and adapted to our needs with the sun-web.xml, which is not really nice but can be done as part of the deployment process.
Some of them are more tricky in respect to licensing agreements and other stuffs and we are not allowed to change ANYTHING in the received artifactts (again, don't ask me why, I didn't sign the contracts either). This makes it a lot more difficult to change the declared resources to be mapped to real ones or to add security groups ect.
What I would like is a possibility to deploy a JEE artifact, through analysing the package, the wizard ask me for the mapping of the different resources (mapping at deployment time) and at the end, ask me if I want to save the mappings in a plan jar file. This would be helpful for the other plattform as I don't really want the prod guys to do it by hand (I give them the ear and the plan jar and a script file to install everything).
I hope it's better understandable...
> > 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?
>
No, it's not really for the developer (but I guess he WILL profit from the compartimentalisation of GF as well).
I would like to be able to create GF installations that are different from each other. One will be just the web tier, one just the business tier, one just the messaging tier, one just the JBI tier (this is just an example. I don't REALLY want to have everything separate, but I'd like the possibility to do so).
Doing it from the web tier and downloading components may be cool for developers, but as soon as you want a stable plattform for the production, you'd like to have a big install package with everything and be able to install only the components you need through an install script (like the current GFv2 version with the ant install script). You define the install script once and use it to install all the different plattforms...
Why:
1) As you may know, doing everything in a single JVM is pretty silly (the runtime deterioration due to the garbage collector is exponential to the size of the JVM) and when you have a lot of components acting together in on instance, some problem arise. If you have an application using 1 GB of mem by itself (using in memory caches as an example) and using in memory messaging + JBI... well you can get pretty strange errors (like a silly out of memory exception if you get too much messages). The possibility to separate and specialize the different layers would be nice. The fact that all of them would be running GF would help tremendously. the specializing could be done at a later step for optimisation purposes and/or could be added in the cluster (2 Web Tier, 2 Business Tier in a cluster, GF handles everything :D)
2) The whole GF is becoming bigger (which is a good thing!) but the administration should still be kept simple (as it is now). This would be helped by the ability to install only the components you need and seeing them in the Admin GUI to manage (like, if you don't need the JBI, then don't install it and don't see it in the GUI). This doesn't mean that components that are needed won't be installed (is the JBI a core component?) but that the administrator won't be able to add functions and configure it.
hope this helps
> > That's about it :D
> > greets
> > jeremie
>
> Great feedback, jeremie. Thanks!
[Message sent by forum member 'granat' (granat)]
http://forums.java.net/jive/thread.jspa?messageID=244029