|
Replies:
89
-
Last Post:
Nov 26, 2007 11:08 AM
by: John Clingan
|
|
|
|
|
|
|
GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Oct 30, 2007 12:13 PM
|
|
|
If you have ideas of features or enhancements that you want in
GlassFish V3, read on!
GlassFish V1 was all about developer productivity and Java EE 5.
GlassFish V2 adds enterprise features such as clustering and
centralized administration. Now that GlassFish V2 has been released,
it is time to begin planning for GlassFish V3. Before doing so, there
needs to be a clear direction of where we are headed. We have outlined
the high level themes for GlassFish V3 here (feel free to provide
feedback on the themes):
http://wiki.glassfish.java.net/Wiki.jsp?page=GlassFishV3Themes
We would like to drill down a step further and begin to define
GlassFish V3 with community involvement. That means you! Is there a
feature or enhancement that you would like to see in GlassFish V3?
Perhaps to make it easier to use or more relevant for your work
environment?
Please feel free to participate! I'd like to begin the discussion on
this alias. Feel free to contact me directly as well at John dot
Clingan at Sun dot COM. Depending on the level of interest, we can
also set up a conference call and discuss in real time.
Here are some sample questions that may stimulate some ideas:
- A feature that would make software development significantly easier
- A feature that differentiates GlassFish V3 from other application
servers
- A feature that is available with application server X, and would
really benefit users if it were also in GlassFish V3
- GlassFish would be easier to use if ...
- If GlassFish had this feature I could deploy it to a broader
production environment
Thanks!
John Clingan
GlassFish / Sun Application Server Group Product Manger
John dot Clingan at Sun dot COM
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Oct 30, 2007 5:28 PM
in response to: John Clingan
|
|
|
A couple ideas off the top of my head:
- Provide a way (if there isn't already one) to deploy exploded
archives, and to develop right out of that folder. Maybe even a pointer
to some other folder (/home/ryan/dev/project1/web/) so we don't have to
rebuild, deploy, and recreate the session when tweaking screens etc. I
waste a lot of time doing this, and our PHP guys think it's funny. I
hear about Tomcat users making a change to a JSP, pressing save then
refresh.
- Make a way for GlassFish to be used in a shared hosting environment
where every hosting customer has their own admin console, virtual
servers, or whatever. Let each customer deploy, redeploy, undeploy,
manage JDBC, etc. I know there are issues with shared JVMs... find an
innovative solution. Take over the shared Tomcat hosting market.
- Add support for different custom roles in the admin GUI. I want to be
able to give our support staff access to manage JCA connection pools,
read logs, and a few other basic things but nothing else.
- Somewhere I read that you can't use wildcards in virutal host names?
For example: *.mycompany.com is served by webapp1. This probably
prevents certain apps from being used on GlassFish, like JIRA? Not
sure, haven't tried.
Ryan
John Clingan wrote:
> If you have ideas of features or enhancements that you want in
> GlassFish V3, read on!
>
> GlassFish V1 was all about developer productivity and Java EE 5.
> GlassFish V2 adds enterprise features such as clustering and
> centralized administration. Now that GlassFish V2 has been released,
> it is time to begin planning for GlassFish V3. Before doing so, there
> needs to be a clear direction of where we are headed. We have outlined
> the high level themes for GlassFish V3 here (feel free to provide
> feedback on the themes):
> http://wiki.glassfish.java.net/Wiki.jsp?page=GlassFishV3Themes
>
> We would like to drill down a step further and begin to define
> GlassFish V3 with community involvement. That means you! Is there a
> feature or enhancement that you would like to see in GlassFish V3?
> Perhaps to make it easier to use or more relevant for your work
> environment?
> Please feel free to participate! I'd like to begin the discussion on
> this alias. Feel free to contact me directly as well at John dot
> Clingan at Sun dot COM. Depending on the level of interest, we can
> also set up a conference call and discuss in real time.
>
> Here are some sample questions that may stimulate some ideas:
>
> - A feature that would make software development significantly easier
> - A feature that differentiates GlassFish V3 from other application
> servers
> - A feature that is available with application server X, and would
> really benefit users if it were also in GlassFish V3
> - GlassFish would be easier to use if ...
> - If GlassFish had this feature I could deploy it to a broader
> production environment
>
> Thanks!
> John Clingan
> GlassFish / Sun Application Server Group Product Manger
>
> John dot Clingan at Sun dot COM
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Oct 30, 2007 5:43 PM
in response to: Ryan de Laplante
|
|
|
On Oct 30, 2007, at 5:28 PM, Ryan de Laplante wrote:
> A couple ideas off the top of my head:
>
> - Provide a way (if there isn't already one) to deploy exploded
> archives, and to develop right out of that folder. Maybe even a
> pointer to some other folder (/home/ryan/dev/project1/web/) so we
> don't have to rebuild, deploy, and recreate the session when
> tweaking screens etc. I waste a lot of time doing this, and our PHP
> guys think it's funny. I hear about Tomcat users making a change
> to a JSP, pressing save then refresh.
>
> - Make a way for GlassFish to be used in a shared hosting
> environment where every hosting customer has their own admin
> console, virtual servers, or whatever. Let each customer deploy,
> redeploy, undeploy, manage JDBC, etc. I know there are issues with
> shared JVMs... find an innovative solution. Take over the shared
> Tomcat hosting market.
Delegated administration. This is currently listed as a "medium"
priority and we sure would like to get more feedback on this directly
from hosting providers!
> - Add support for different custom roles in the admin GUI. I want
> to be able to give our support staff access to manage JCA connection
> pools, read logs, and a few other basic things but nothing else.
>
Role-based access control is pretty high in the priority list. More
use cases would be helpful if you can expand on this.
> - Somewhere I read that you can't use wildcards in virutal host
> names? For example: *.mycompany.com is served by webapp1. This
> probably prevents certain apps from being used on GlassFish, like
> JIRA? Not sure, haven't tried.
>
We'll look into the others. Thanks.
>
>
> Ryan
>
>
> John Clingan wrote:
>> If you have ideas of features or enhancements that you want in
>> GlassFish V3, read on!
>>
>> GlassFish V1 was all about developer productivity and Java EE 5.
>> GlassFish V2 adds enterprise features such as clustering and
>> centralized administration. Now that GlassFish V2 has been
>> released, it is time to begin planning for GlassFish V3. Before
>> doing so, there needs to be a clear direction of where we are
>> headed. We have outlined the high level themes for GlassFish V3
>> here (feel free to provide feedback on the themes):
>> http://wiki.glassfish.java.net/Wiki.jsp?page=GlassFishV3Themes
>>
>> We would like to drill down a step further and begin to define
>> GlassFish V3 with community involvement. That means you! Is there a
>> feature or enhancement that you would like to see in GlassFish V3?
>> Perhaps to make it easier to use or more relevant for your work
>> environment?
>> Please feel free to participate! I'd like to begin the discussion
>> on this alias. Feel free to contact me directly as well at John dot
>> Clingan at Sun dot COM. Depending on the level of interest, we can
>> also set up a conference call and discuss in real time.
>>
>> Here are some sample questions that may stimulate some ideas:
>>
>> - A feature that would make software development significantly easier
>> - A feature that differentiates GlassFish V3 from other application
>> servers
>> - A feature that is available with application server X, and would
>> really benefit users if it were also in GlassFish V3
>> - GlassFish would be easier to use if ...
>> - If GlassFish had this feature I could deploy it to a broader
>> production environment
>>
>> Thanks!
>> John Clingan
>> GlassFish / Sun Application Server Group Product Manger
>>
>> John dot Clingan at Sun dot COM
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
>> For additional commands, e-mail: users-help@glassfish.dev.java.net
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Oct 30, 2007 6:21 PM
in response to: Ryan de Laplante
|
|
|
Ryan,
Ryan de Laplante wrote:
> A couple ideas off the top of my head:
>
> - Provide a way (if there isn't already one) to deploy exploded
> archives, and to develop right out of that folder. Maybe even a
> pointer to some other folder (/home/ryan/dev/project1/web/) so we
> don't have to rebuild, deploy, and recreate the session when tweaking
> screens etc. I waste a lot of time doing this, and our PHP guys think
> it's funny. I hear about Tomcat users making a change to a JSP,
> pressing save then refresh.
This already works in GlassFish. Just use asadmin's "deploydir" option,
and specify the location
of your folder. In it, you can modify your JSPs, save, and refresh.
Jan
>
> - Make a way for GlassFish to be used in a shared hosting environment
> where every hosting customer has their own admin console, virtual
> servers, or whatever. Let each customer deploy, redeploy, undeploy,
> manage JDBC, etc. I know there are issues with shared JVMs... find
> an innovative solution. Take over the shared Tomcat hosting market.
>
> - Add support for different custom roles in the admin GUI. I want to
> be able to give our support staff access to manage JCA connection
> pools, read logs, and a few other basic things but nothing else.
>
> - Somewhere I read that you can't use wildcards in virutal host names?
> For example: *.mycompany.com is served by webapp1. This probably
> prevents certain apps from being used on GlassFish, like JIRA? Not
> sure, haven't tried.
>
>
>
> Ryan
>
>
> John Clingan wrote:
>
>> If you have ideas of features or enhancements that you want in
>> GlassFish V3, read on!
>>
>> GlassFish V1 was all about developer productivity and Java EE 5.
>> GlassFish V2 adds enterprise features such as clustering and
>> centralized administration. Now that GlassFish V2 has been released,
>> it is time to begin planning for GlassFish V3. Before doing so, there
>> needs to be a clear direction of where we are headed. We have
>> outlined the high level themes for GlassFish V3 here (feel free to
>> provide feedback on the themes):
>> http://wiki.glassfish.java.net/Wiki.jsp?page=GlassFishV3Themes
>>
>> We would like to drill down a step further and begin to define
>> GlassFish V3 with community involvement. That means you! Is there a
>> feature or enhancement that you would like to see in GlassFish V3?
>> Perhaps to make it easier to use or more relevant for your work
>> environment?
>> Please feel free to participate! I'd like to begin the discussion on
>> this alias. Feel free to contact me directly as well at John dot
>> Clingan at Sun dot COM. Depending on the level of interest, we can
>> also set up a conference call and discuss in real time.
>>
>> Here are some sample questions that may stimulate some ideas:
>>
>> - A feature that would make software development significantly easier
>> - A feature that differentiates GlassFish V3 from other application
>> servers
>> - A feature that is available with application server X, and would
>> really benefit users if it were also in GlassFish V3
>> - GlassFish would be easier to use if ...
>> - If GlassFish had this feature I could deploy it to a broader
>> production environment
>>
>> Thanks!
>> John Clingan
>> GlassFish / Sun Application Server Group Product Manger
>>
>> John dot Clingan at Sun dot COM
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
>> For additional commands, e-mail: users-help@glassfish.dev.java.net
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 17, 2007 8:00 AM
in response to: Jan.Luehe@Sun.COM
|
|
|
hi,Jan,you said:
>This already works in GlassFish. Just use asadmin's "deploydir" option,
>and specify the location of your folder. In it, you can modify your JSPs,
save, and refresh.
How to do it?
I switched from Tomcat, and use Eclipse plugin to start GlassFish.
Every time when I update a client file (html,js), Eclipse auto start to run
deploydir. As Ryan de Laplante wrote,
'I waste a lot of time doing this'!
--
View this message in context: http://www.nabble.com/GlassFish-V3-planning---What-do-*you*-want-in-GlassFish-V3--tf4720672.html#a13810407
Sent from the java.net - glassfish users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 18, 2007 5:45 AM
in response to: fangzx
|
|
|
Unfortunately I think that is the limit of eclipses 'integration'. I
have a coworker who uses it as well, and yes, it does just do a
complete redeploy for every change, and yes it sucks up a lot of time.
One simple way to get around this is to not use Eclipse to do the
deploy/undeploy. If you have a build script already that makes a
directory that you then WAR that should be enough. Do a manual
'deploydir', adn when you have a change just run a build and update
the directory. If you have a class change you'll need to restart GF,
jsp changes should be seen automatically. It's still not optimal, but
it might help.
-Nick
p.s. You can deploy a directory through the admin console or through
the command line, both options I believe are covered in the docs, but
it is fairly straight forward to do.
>
> How to do it?
>
> I switched from Tomcat, and use Eclipse plugin to start GlassFish.
> Every time when I update a client file (html,js), Eclipse auto start to run
> deploydir. As Ryan de Laplante wrote,
> 'I waste a lot of time doing this'!
>
>
>
>
> --
> View this message in context: http://www.nabble.com/GlassFish-V3-planning---What-do-*you*-want-in-GlassFish-V3--tf4720672.html#a13810407
> Sent from the java.net - glassfish users mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 22, 2007 5:17 PM
in response to: Nick Stuart
|
|
|
hi,Nick,thank you for the reply.
I have found a perfect solution to this problem:
http://www.javaeye.com/post/415822 (my blog post, it is in Chinese)
My method in short is:
(1)don't use Eclipse autoDeploy function, use GlassFish's dir deploy
function.
(2)use .reload file to control reload of changed java class.
--
View this message in context: http://www.nabble.com/GlassFish-V3-planning---What-do-*you*-want-in-GlassFish-V3--tf4720672.html#a13905702
Sent from the java.net - glassfish users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 18, 2007 7:58 AM
in response to: fangzx
|
|
|
fangzx wrote:
> hi,Jan,you said:
>
>> This already works in GlassFish. Just use asadmin's "deploydir" option,
>> and specify the location of your folder. In it, you can modify your JSPs,
>>
> save, and refresh.
>
> How to do it?
>
> I switched from Tomcat, and use Eclipse plugin to start GlassFish.
> Every time when I update a client file (html,js), Eclipse auto start to run
> deploydir. As Ryan de Laplante wrote,
> 'I waste a lot of time doing this'!
>
>
>
This is the default seting for Eclipse 3.3 (not from server plugin), but
you can turn it off via the Eclipse options somewhere,
Ludo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 1, 2007 3:25 AM
in response to: John Clingan
|
|
|
There are a number of enchancements that would make glassfish into an even more competent app server, able to cater to the larger enterprise deployment. Here is a non exclusive list and I'm happy to take this discussion further if you'd like.
* Versioned application deployment - There can be multiple levels of sophistication with-regards to this. The basic idea is that application deployments will handled a little more as a source control system which will enable rollback to a previous version if needed
* Versioned application configuration - Right now the configuration changes are kept in a single file so there is no way to go back to a "last known good" configuration. Also when doing configuration changes they should be able to be grouped into a "changeset" which is the unit of configurauiton which will be applied and rolled-back
* Transactional aware cache - There are two uses of a distributed cache. As a second level cache for a persistence provider like Toplink esstentials and Hibernate, but also as a free-standing service. For both of these uses it should be possible to configure the cache to be transactional so that cache updates will be updated and commited in the same transaction as the operation in the app server. Otherwise we risk using invalid cached data and if we cannot rely on the cache we need to hit the database anyways which is what we wanted to avoid in the first place
* Synchronous state replication should be possible and easy - In concert with the transactional cache bullet, this is a partial solution, not guaranteeing full transactional semantics for cache updates, it still synchronous so that there is less risk of cached data losses
* Pluggable app server services, e.g. persistence providers
* Content sensitive call tracing filter function - The call tracing functionality can today filter on users, but this is quite corse level. For solutions where the user is another server which generates high-load in itself it becomes impossible to turn-on traceing for such a user. What would be really smooth would be the option to configure a filter which would inspect the actual call parameters to the operation and determine if it should be traced or not
* AOP framework support - Other app servers integrate AOP frameworks which can be very efficient in solving some application level design and monitoring issues. GF should include such a framework
* Support in the GUI for configuring common load balancing solutions on the market, e.g. mod_jk
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 1, 2007 12:01 PM
in response to: jesper_soderlund
|
|
|
This is a wonderful list and thank you for spending the time to write it up! Let us absorb this a bit and we'll talk more.
Thanks!
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 2, 2007 12:44 AM
in response to: jclingan
|
|
|
Sure. Another feature request that would have been very useful for me on a number of occasions is:
* Prioritized resource scheduling - When the server comes under heavy load and processing thread pools / connection pools or other computing resources become drained. It should be possible to make a prioritization between different applications deployed in the application server how to distribute the now scarce computing resources. In the traditional server architecture this can be handled though OS-level prioritizations, e.g. Solaris has quite good tools for this. Since the app-server is a single OS-process, those tools become useless  . It should thus be possible to define weights between applications deployed for distributing resources, ensuring that no application is completly starved but more resources distributed to prioritized apps.
Not all applications are equal in a tight resource situation
Message was edited by: jesper_soderlund
|
|
|
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 5, 2007 2:44 AM
in response to: jr158900
|
|
|
That request is very specific on JDBC connection pooling but I see the issue as larger than just the DB-conections. Another critical resources in these situations are the request processing threads, e.g. MDB-threadpool, thread pool the web connection layer, the thread pool executing the EJB timers, JMS-destination thread pools.
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 1, 2007 11:21 AM
in response to: John Clingan
|
|
|
Simple. Give it a meaningful name which expresses what the thing actually does. You have apparently never had to deal with the blank stares of customers when you talk about using "glassfish" as the product platform. Give it a simple, dull, clean name.
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 1, 2007 11:21 AM
in response to: ewin
|
|
|
> You have apparently never had to deal with the blank stares...
That is not so. I (and many others) have been in _MANY_ naming
discussions. Trust me, it is not easy. Any name you can think of is
either taken or overly restrictive.
In any case, the opportunity to change the name was two years ago.
- eduard/o
glassfish@javadesktop.org wrote:
> Simple. Give it a meaningful name which expresses what the thing actually does. You have apparently never had to deal with the blank stares of customers when you talk about using "glassfish" as the product platform. Give it a simple, dull, clean name.
> [Message sent by forum member 'ewin' (ewin)]
>
> http://forums.java.net/jive/thread.jspa?messageID=243333
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 1, 2007 11:26 AM
in response to: Eduardo Pelegri...
|
|
|
When talking to customers, refer to it as Sun Application Server, or Sun
Java System Application Server, instead of GlassFish. That's what we do
and our customers know who Sun is. That should be simple, dull, and
clean enough for you.
Ryan
Eduardo Pelegri-Llopart wrote:
> > You have apparently never had to deal with the blank stares...
>
> That is not so. I (and many others) have been in _MANY_ naming
> discussions. Trust me, it is not easy. Any name you can think of is
> either taken or overly restrictive.
>
> In any case, the opportunity to change the name was two years ago.
>
> - eduard/o
>
>
> glassfish@javadesktop.org wrote:
>> Simple. Give it a meaningful name which expresses what the thing
>> actually does. You have apparently never had to deal with the blank
>> stares of customers when you talk about using "glassfish" as the
>> product platform. Give it a simple, dull, clean name.
>> [Message sent by forum member 'ewin' (ewin)]
>>
>> http://forums.java.net/jive/thread.jspa?messageID=243333
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
>> For additional commands, e-mail: users-help@glassfish.dev.java.net
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 1, 2007 5:28 PM
in response to: Ryan de Laplante
|
|
|
I would like to support the feature requests made earlier in this thread about deployment versioning and configuration versioning.
Just as there is a difference in quality between an application server that has manually configurable clustering support (like JBoss) and an application server that has a comprehensive and exhaustive, fixed approach to clustering including admin console support, distribution of deployments etc..(like Glassfish) , just so there is also a difference between being able to simply deploy applications and having a comprehensive builtin solution for "staging".
Content Management Systems provide staging capabilities for reviewing and publishing document based content and application servers should be able to do the same for applications.
There are two further capabilities that pretty much all currently available application servers are lacking and that would make Glassfish V3 stand out. In fact, the following two features are actually something that every Java enterprise developer has been hoping for for years whilst application server vendors have successfully managed to neglect these crucial needs.
1.) Comprehensive application isolation
It is quite a usual case to have the need to deploy the same application more than once on a single server instance. For example: having a production-version, a validation version, a development version, a test version etc. of the same application available for different user groups. One could expand this list. Think of staging again: key users need to review and test a new application release and grant permission for it to me moved into production. The application would have to be deployed
and wired to mockup backend systems a.s.o.. It is quite awkward to brag to superiors about the sophistication of JEE based technology in constrast to other solutions and then having to admit that 10 different server instances need to be operated in order to host the same application in 10 different setups.
It is easy to deploy different applications to the same server instance but it is virtually impossible to deploy two variations of the same application. On Jboss for instance, one would have to rewrite tons of descriptors in order to have the applications use different JNDI names etc. and in the end, it is still not possible because the JNDI names for Message Driven Beans cannot be customized.
It is an endless game of pain. Meanwhile, PHP developers cannot even begin to understand why such things should be such a problem in the Java world.
2.) To a PHP developer it is incomprehensible why one should have such a heavyweight build-deploy -test cycle in JEE. The company I'm currently working for has a build skript for assembling one JEE application and executing this script takes 10 Minutes. Even if it took only 1 second to deploy a modification, this would still be unacceptable.
Some application servers have come up with lukewarm solutions to half of the zero-deployment time issue, by allowing to deploy JSP files to a directory or having exploded deployment archives, or being able to update a single JSP file into an existing deployment. JBoss came up with a servlet filter that fetches JSP pages from the workspace location. So now, developers even need to customize their applications just to achieve something that should be out-of-the box in the first place.
Furthermore, these solutions most often only work for the web-layer, not for all parts of a JEE application.
Working with Eclipse, the assembly directives for JEE applications are mere configurations made within the IDE. When deploying such an application, the configuration settings are used to physically assemble a deployment unit and then copy the whole shebang to an application server.
At the very least, IDE plugins for Glassfish V3 should be able to support incremental deployments, meaning that the EAR archive built by Eclipse isn fully copied to the server but instead, the contents of the EAR to be deployed and the already deployed one should be compared and only the differing resoures should be transmitted. The server should then update the existing application with the incremental changes.
Additionally, I don't see any point in the current behavior of Eclipse server plugins to build physical EAR archives based on the eclipse configuration instead of using the configuration to just emulate an EAR archive view. This can be done with Eclipse for the latest Tomcat releases but of course only for .war archives and leads to zero build time. This support needs to be extended to all JEE deployment units. This probably requires the server to be based on some sort of virtual file system layer and the Eclipse server plugin to play along and emulate a virtual filesystem for the server mirroring the correct deployment structure of an application that has a different source-level organization.
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 1, 2007 6:19 PM
in response to: wtff
|
|
|
That'd be all well and good save that PHP and Java are completely different animals.
PHP doesn't have the lifecycle constraints the EJB components have. They also don't have the persistent class mechanisms that Java has (since you're running in a live heap). There is no protocol in Java to change the structure of an object on the fly, for example. But a dynamic loader needs to be able to support that kind of thing.
Of course PHP doesn't have that problem because everything is interpreted at request time and thrown away, there is no persistent state within the heap, no shared binary structures from request to request. Everything is made fresh on load.
What you want sound wonderful, but there are limitations imposed both via the spec itself, as well as the implementations that make this a Hard Problem. If it wasn't hard, we'd have it well solved by now.
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 2, 2007 1:47 AM
in response to: whartung
|
|
|
I absolutely agree.
However, the server doesn't need to be able to load classes dynamically. The proposed changes do not entail that it does. The server could still reload the whole application on each update. The improvement would still be that only the files get transmitted to the server that have been modified. The server could then assemble a new deployment based on the existing one and the modified Increment and then deploy this new, self-assembled application archive in the traditional way.
The proposal to get rid of the need for physical deployment-unit assembly does not require dynamic class definition reloadin either. The server could still act in the classical sense and reload an application in total for each update, but a good deal of time could be saved if IDEs didn't need to physical assemble an application before deployment. The only need for this is because the development arrangements of application artifacts differs from the deployment structure and because IDEs have no means to provide servers with virtual deployment units.
My imagination is such that a server would be able to deploy an application by being provided with a link to a virtual filesystem location. At this location, the server would expect to find a correct application archive atructure. The top level directory would have to contain a META-INF directory with an application.xml file in it...
An IDE would provide the server with a virtual filesystem link that leads back to a virtual filesystem service provided by the IDE itself. If the server requested to receive a directory listing for his deployment link, the IDE would return a correct application archive structure. If the server consequently tried to access the META-INF/application.xml file, it would again connect to the IDEs virtual filesystem service and request this file. The IDE would consult it's project configuration to resolve the META-INF/application.xml file to a project location myproject/meta/deploymentdescritors/application-config1.xml.
Of course, the need to do full redeployments on server-side would still be time consuming but the development experience would be much better. Test the virtual deployment caps that are implemented in Eclipse for Tomcat 6 webservers and you will see how perfect the approach is.
BTW: the approach to physically build a deployment unit should survive also for deployments that are outside the scope of the code-deploy-test cycle.
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 2, 2007 9:25 AM
in response to: wtff
|
|
|
So I am a little unclear how different this proposal is from what we
support today with directory deployment.
With directory deployment the IDE and glassfish share the application
directory (IDE compiles in it and GF loads classes from it) so there
is no need for war packaging, transfer to the server type of action at
each iterative deployment cycle.
With netbeans being capable of leveraging directory deployment, we are
pretty much doing what you described below (except we don't use a
virtual file system but just an exploded directory structure that the
IDE and GlassFish have agreed upon).
So the war file redeployment is *very* fast when you use netbeans with
glassfish, I see no reason why other IDEs could not leverage that
directory deployment feature.
Is there something else you would want to see ?
On Nov 2, 2007, at 1:47 AM, glassfish@javadesktop.org wrote:
> I absolutely agree.
> However, the server doesn't need to be able to load classes
> dynamically. The proposed changes do not entail that it does. The
> server could still reload the whole application on each update. The
> improvement would still be that only the files get transmitted to
> the server that have been modified. The server could then assemble a
> new deployment based on the existing one and the modified Increment
> and then deploy this new, self-assembled application archive in the
> traditional way.
>
> The proposal to get rid of the need for physical deployment-unit
> assembly does not require dynamic class definition reloadin either.
> The server could still act in the classical sense and reload an
> application in total for each update, but a good deal of time could
> be saved if IDEs didn't need to physical assemble an application
> before deployment. The only need for this is because the development
> arrangements of application artifacts differs from the deployment
> structure and because IDEs have no means to provide servers with
> virtual deployment units.
>
> My imagination is such that a server would be able to deploy an
> application by being provided with a link to a virtual filesystem
> location. At this location, the server would expect to find a
> correct application archive atructure. The top level directory would
> have to contain a META-INF directory with an application.xml file in
> it...
> An IDE would provide the server with a virtual filesystem link that
> leads back to a virtual filesystem service provided by the IDE
> itself. If the server requested to receive a directory listing for
> his deployment link, the IDE would return a correct application
> archive structure. If the server consequently tried to access the
> META-INF/application.xml file, it would again connect to the IDEs
> virtual filesystem service and request this file. The IDE would
> consult it's project configuration to resolve the META-INF/
> application.xml file to a project location myproject/meta/
> deploymentdescritors/application-config1.xml.
>
>
> Of course, the need to do full redeployments on server-side would
> still be time consuming but the development experience would be much
> better. Test the virtual deployment caps that are implemented in
> Eclipse for Tomcat 6 webservers and you will see how perfect the
> approach is.
> BTW: the approach to physically build a deployment unit should
> survive also for deployments that are outside the scope of the code-
> deploy-test cycle.
> [Message sent by forum member 'wtff' (wtff)]
>
> http://forums.java.net/jive/thread.jspa?messageID=243442
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 2, 2007 10:00 AM
in response to: Jerome Dochez
|
|
|
Now, just for the record, I'm talking about NB 5.5.1. Perhaps this has changed for 6.0.
Right now, Netbeans does a couple of "smart" things, and one "dumb" thing with regards to WARs.
First, it does do a directory deploy -- which is great.
Next, it has some awareness of what's changed, so that if you simply make, say, a JSP change, NB doesn't really do anything on the server -- it makes the change in place, and when you hit the page again, the JSP reloads and rebuilds. One of the nice things about GF is that it can precompile the JSPs on deploy, but you can still make JSP changes in place. I just wish we could easily compile JSPs in advance as well, but that's a different issue.
Anyway, if you make a class change, then NB will tell the container to actually restart the web app, since you need to reload the classes. So that's the other smart thing it does.
The only "dumb" thing it does is that it builds the WAR at this point, even tho, in theory, we don't need it. It DOES appear to be an incremental WAR update, but I'm not sure. But some would argue that this step need not be done at all, at least at this stage of development. So, that could shave precious seconds from the turnaround.
Now, NB 5.5.1 does NOT do an incremental, directory deploy of EARs. Those are rebuilt from scratch each time, and the container application restarted.
I think it would be interesting, specifically with EARs, if GF (since we're talking about GF here, really, not NB :-)) had the ability to incrementally redeploy EARs. Specifically, it would be nice if rather than restarting the entire EAR application when an embedded WAR changes, just restart the affected WAR. Basically, be more considerate about the level of the change and its affect on the restart. If I have a WAR in an EAR with 2 other WARs, and a bunch of EJBs, it would be nice to not have to reload the whole kit for a change in one component. Obviously, if you change something at the root, then you need to reload.
I think NB 6 is giving us directory deploys of EARs as well, but I'm not sure.
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 20, 2007 1:16 PM
in response to: whartung
|
|
|
glassfish@javadesktop.org wrote:
> Now, just for the record, I'm talking about NB 5.5.1. Perhaps this has changed for 6.0.
>
> Right now, Netbeans does a couple of "smart" things, and one "dumb" thing with regards to WARs.
>
> First, it does do a directory deploy -- which is great.
>
> Next, it has some awareness of what's changed, so that if you simply make, say, a JSP change, NB doesn't really do anything on the server -- it makes the change in place, and when you hit the page again, the JSP reloads and rebuilds. One of the nice things about GF is that it can precompile the JSPs on deploy, but you can still make JSP changes in place. I just wish we could easily compile JSPs in advance as well, but that's a different issue.
>
> Anyway, if you make a class change, then NB will tell the container to actually restart the web app, since you need to reload the classes. So that's the other smart thing it does.
>
> The only "dumb" thing it does is that it builds the WAR at this point, even tho, in theory, we don't need it. It DOES appear to be an incremental WAR update, but I'm not sure. But some would argue that this step need not be done at all, at least at this stage of development. So, that could shave precious seconds from the turnaround.
>
This is fixed in NetBeans 6.
Petr
> Now, NB 5.5.1 does NOT do an incremental, directory deploy of EARs. Those are rebuilt from scratch each time, and the container application restarted.
>
> I think it would be interesting, specifically with EARs, if GF (since we're talking about GF here, really, not NB :-)) had the ability to incrementally redeploy EARs. Specifically, it would be nice if rather than restarting the entire EAR application when an embedded WAR changes, just restart the affected WAR. Basically, be more considerate about the level of the change and its affect on the restart. If I have a WAR in an EAR with 2 other WARs, and a bunch of EJBs, it would be nice to not have to reload the whole kit for a change in one component. Obviously, if you change something at the root, then you need to reload.
>
> I think NB 6 is giving us directory deploys of EARs as well, but I'm not sure.
> [Message sent by forum member 'whartung' (whartung)]
>
> http://forums.java.net/jive/thread.jspa?messageID=243524
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 8, 2007 1:37 PM
in response to: wtff
|
|
|
glassfish@javadesktop.org wrote:
> I would like to support the feature requests made earlier in this thread about deployment versioning and configuration versioning.
> Just as there is a difference in quality between an application server that has manually configurable clustering support (like JBoss) and an application server that has a comprehensive and exhaustive, fixed approach to clustering including admin console support, distribution of deployments etc..(like Glassfish) , just so there is also a difference between being able to simply deploy applications and having a comprehensive builtin solution for "staging".
> Content Management Systems provide staging capabilities for reviewing and publishing document based content and application servers should be able to do the same for applications.
>
> There are two further capabilities that pretty much all currently available application servers are lacking and that would make Glassfish V3 stand out. In fact, the following two features are actually something that every Java enterprise developer has been hoping for for years whilst application server vendors have successfully managed to neglect these crucial needs.
>
> 1.) Comprehensive application isolation
> It is quite a usual case to have the need to deploy the same application more than once on a single server instance. For example: having a production-version, a validation version, a development version, a test version etc. of the same application available for different user groups. One could expand this list. Think of staging again: key users need to review and test a new application release and grant permission for it to me moved into production. The application would have to be deployed
> and wired to mockup backend systems a.s.o.. It is quite awkward to brag to superiors about the sophistication of JEE based technology in constrast to other solutions and then having to admit that 10 different server instances need to be operated in order to host the same application in 10 different setups.
> It is easy to deploy different applications to the same server instance but it is virtually impossible to deploy two variations of the same application. On Jboss for instance, one would have to rewrite tons of descriptors in order to have the applications use different JNDI names etc. and in the end, it is still not possible because the JNDI names for Message Driven Beans cannot be customized.
> It is an endless game of pain. Meanwhile, PHP developers cannot even begin to understand why such things should be such a problem in the Java world.
>
> 2.) To a PHP developer it is incomprehensible why one should have such a heavyweight build-deploy -test cycle in JEE. The company I'm currently working for has a build skript for assembling one JEE application and executing this script takes 10 Minutes. Even if it took only 1 second to deploy a modification, this would still be unacceptable.
> Some application servers have come up with lukewarm solutions to half of the zero-deployment time issue, by allowing to deploy JSP files to a directory or having exploded deployment archives, or being able to update a single JSP file into an existing deployment. JBoss came up with a servlet filter that fetches JSP pages from the workspace location. So now, developers even need to customize their applications just to achieve something that should be out-of-the box in the first place.
> Furthermore, these solutions most often only work for the web-layer, not for all parts of a JEE application.
> Working with Eclipse, the assembly directives for JEE applications are mere configurations made within the IDE. When deploying such an application, the configuration settings are used to physically assemble a deployment unit and then copy the whole shebang to an application server.
>
> At the very least, IDE plugins for Glassfish V3 should be able to support incremental deployments, meaning that the EAR archive built by Eclipse isn fully copied to the server but instead, the contents of the EAR to be deployed and the already deployed one should be compared and only the differing resoures should be transmitted. The server should then update the existing application with the incremental changes.
>
NetBeans 6.0 + Glassfish V2 already supports incremental deployment of
EARs. I expect we should be able to support this in V3 as well (in NB
6.0, Eclipse is TBD).
-Peter
> Additionally, I don't see any point in the current behavior of Eclipse server plugins to build physical EAR archives based on the eclipse configuration instead of using the configuration to just emulate an EAR archive view. This can be done with Eclipse for the latest Tomcat releases but of course only for .war archives and leads to zero build time. This support needs to be extended to all JEE deployment units. This probably requires the server to be based on some sort of virtual file system layer and the Eclipse server plugin to play along and emulate a virtual filesystem for the server mirroring the correct deployment structure of an application that has a different source-level organization.
> [Message sent by forum member 'wtff' (wtff)]
>
> http://forums.java.net/jive/thread.jspa?messageID=243394
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 2, 2007 10:06 AM
in response to: John Clingan
|
|
|
I would like to be able to be able to easily put an application on "stand by" with a (configurable) "down for maintenance -- coming back soon" message when I need to redeploy an application, or do some other maintenance. Basically have the container put the application offline, without being rude to the users. Right now you need to jump through a bunch of hoops to get that to work.
If you have to take the container down, well, then you're stuck -- but the goal seems to be that the container is a long running piece of software, so that's why I think this functionality should be rolled in to the container rather than be the individual applications responsibility. There should not be a clustering requirement for this as well.
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 2, 2007 10:26 AM
in response to: whartung
|
|
|
yes we have identified this requirement, it's called suspend where the
requests would be queued at low level and wait for the "redeployment"
to be finished. in theory, we would not even have to say anything to
the user (assuming there are not too many outstanding requests), it
would just take a bit longer to be serviced.
would that help ?
On Nov 2, 2007, at 10:06 AM, glassfish@javadesktop.org wrote:
> I would like to be able to be able to easily put an application on
> "stand by" with a (configurable) "down for maintenance -- coming
> back soon" message when I need to redeploy an application, or do
> some other maintenance. Basically have the container put the
> application offline, without being rude to the users. Right now you
> need to jump through a bunch of hoops to get that to work.
>
> If you have to take the container down, well, then you're stuck --
> but the goal seems to be that the container is a long running piece
> of software, so that's why I think this functionality should be
> rolled in to the container rather than be the individual
> applications responsibility. There should not be a clustering
> requirement for this as well.
> [Message sent by forum member 'whartung' (whartung)]
>
> http://forums.java.net/jive/thread.jspa?messageID=243525
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 2, 2007 11:39 AM
in response to: Jerome Dochez
|
|
|
On Friday 02 November 2007 12:26, Jerome Dochez wrote:
> yes we have identified this requirement, it's called suspend where
> the requests would be queued at low level and wait for the
> "redeployment" to be finished. in theory, we would not even have to
> say anything to the user (assuming there are not too many outstanding
> requests), it would just take a bit longer to be serviced.
>
> would that help ?
Great idea.
--
____________________________________________________________
Glenn Holmer gholmer@weycogroup.com
Software Engineer phone: 414-908-1809
Weyco Group, Inc. fax: 414-908-1601
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 2, 2007 3:30 PM
in response to: Jerome Dochez
|
|
|
> yes we have identified this requirement, it's called
> suspend where the
> requests would be queued at low level and wait for
> the "redeployment"
> to be finished. in theory, we would not even have to
> say anything to
> the user (assuming there are not too many outstanding
> requests), it
> would just take a bit longer to be serviced.
>
> would that help ?
I think that would be useful for simple redeploys, but there are times when we do things like DB maintenance while the app is down, so the down time my be longer than a simple delay in request processing. Personally, any thing that took more than 15 to 30 seconds to come back to the user is "broken" in my view. I always feel like something is wrong when that happens.
Also, during our deploys, we check the "compile JSP" option, so on our system it can easily take several minutes just to get the app deployed with the JSPs compiled, this is outside of any other maintenance involved.
Perhaps adding an ability to have the JSPs compile in the background during deployment would help? That way the site is "up" immediately, while JSPs are being built in the background. Now, our sites aren't hit heavily, so it's rarely a race between the user finding uncompiled JSPs (and stuck waiting for them). But on a busy site, I think pre-compiling them all in one go is a better option.
We use Java 5 still, btw, I understand Java 6 does better with JSPs, but we're not there yet.
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 3, 2007 1:31 PM
in response to: whartung
|
|
|
|
|
Hi
Thank you for opening this thread.
Here is a list of what I like to see in GF v3.
1- Package for Z Linux and Z OS.
2- A complete mentoring section with live graph showing the statistics
3- A panel to monitor logs, I mean logs should be easier to read/find
and track.
4-A better clustering management, setting up a Weblogic 10 cluster is
easier than GF and it shows that there are some area of improvement in
this section.
5- an easy and affordable interface to manage Digital certificate in
glassfish key stores, whether it is in developer profile or enterprise
profile.
thats all which i can say now
glassfish@javadesktop.org wrote:
>> yes we have identified this requirement, it's called
>> suspend where the
>> requests would be queued at low level and wait for
>> the "redeployment"
>> to be finished. in theory, we would not even have to
>> say anything to
>> the user (assuming there are not too many outstanding
>> requests), it
>> would just take a bit longer to be serviced.
>>
>> would that help ?
>>
>
> I think that would be useful for simple redeploys, but there are times when we do things like DB maintenance while the app is down, so the down time my be longer than a simple delay in request processing. Personally, any thing that took more than 15 to 30 seconds to come back to the user is "broken" in my view. I always feel like something is wrong when that happens.
>
> Also, during our deploys, we check the "compile JSP" option, so on our system it can easily take several minutes just to get the app deployed with the JSPs compiled, this is outside of any other maintenance involved.
>
> Perhaps adding an ability to have the JSPs compile in the background during deployment would help? That way the site is "up" immediately, while JSPs are being built in the background. Now, our sites aren't hit heavily, so it's rarely a race between the user finding uncompiled JSPs (and stuck waiting for them). But on a busy site, I think pre-compiling them all in one go is a better option.
>
> We use Java 5 still, btw, I understand Java 6 does better with JSPs, but we're not there yet.
> [Message sent by forum member 'whartung' (whartung)]
>
> http://forums.java.net/jive/thread.jspa?messageID=243608
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
>
>
[att1.html]
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 3, 2007 3:07 AM
in response to: Jerome Dochez
|
|
|
It would be useful in some situations, though not as a catch-all to address the original feature request, mainly due to issues raised elsewhere in this thread. For example, DB-schema upgrades etc.
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 3, 2007 4:54 AM
in response to: Jerome Dochez
|
|
|
I think that in Sun ONE 7 when you redeploy an application, Sun ONE create a new deploy folder APPLICATION_${version_number}.
It would be great if glassfish could keep two versions of the same applications. The active sessions of users who are using the application still using its version and new users will be redirected to the new version.
This could help to eliminate maintenance times. I don't know if this is posible on J2EE aplication using JNDI but it looks not very dificult on simple Web Applications.
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 3, 2007 8:47 AM
in response to: John Clingan
|
|
|
I would like to have an improved logging. My first impression using Glassfish with Netbeans was, "Whow what a mess".
1. The logging of all components should agree on a verbosity levels.
2. The logging of all components should be easily located and the verbosity should be easily changed. I would like to see a unique way to set the verbosity for all components.
3. The logging should focus on the user instead of developer (of the component). This means using the vocabulary the user knows instead of using internal names like implementation classes.
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 3, 2007 2:24 PM
in response to: pinus
|
|
|
Well, within Glassfish proper, you pretty much have all of this right now.
GF proper doesn't use the class names for its log catagories, rather it uses catagories like Web Container and Persistence (tho it does note which packages those categories encompass). The GF logging page tells you the verbosity of each category, and that page allows easy configuration of verbosity levels, including application specific ones (though you need to know the names before hand).
If your applications followed similar guidelines, then all would be rosy, but truth is that GF is only in control of so much. It might be iteresting if GF presented all of the loggers that it DID know about to the user in the GUI, but even then it can only present those loggers that it has seen configured during the current instance of the server. It can't know anything about loggers that haven't been set up yet (for example in code that has not yet been run).
For example, GF uses JDK logging. If your Application uses JDK logging as well, then the logging page lets you set the verbosity of your categories (Through the properties section -- consult the FAQ in the Wiki).
But if the application being deployed uses, say, log4j, or any other framework, then you're out of luck as GF doesn't know anything about log4j.
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 5, 2007 1:41 PM
in response to: whartung
|
|
|
That's what shows up on my console when I start glassfish.
It starts with a JDK log like looking entry, "oh, the user probably wants to know all parameters". This looks quite verbose to me.
Other lines have no prefix, to what ever component this lines belong.
Some lines have "xxxxnnnn:" prefix, others have "[xxxxxxxx]" prefix.
What I meant on agreeing with verbosity level is that all components produce the same amount of output with the same verbosity level. If one component starts with a whole parameter dump on INFO level all components should do. Or no component should do.
The glassfish logfile:
----Log File Rotated---
05.11.2007 22:14:47 com.sun.enterprise.admin.servermgmt.launch.ASLauncher buildCommand
INFO:
/opt/java/jdk1.6.0/bin/java
-Dcom.sun.aas.instanceRoot=/home/haug/programs/glassfish-v2-b58g/domains/domain1
-Dcom.sun.aas.ClassPathPrefix=
-Dcom.sun.aas.ClassPathSuffix=
-Dcom.sun.aas.ServerClassPath=
-Dcom.sun.aas.classloader.appserverChainJars.ee=
-Dcom.sun.aas.classloader.appserverChainJars=admin-cli.jar,admin-cli-ee.jar,j2ee-svc.jar
-Dcom.sun.aas.classloader.excludesList=admin-cli.jar,appserv-upgrade.jar,sun-appserv-ant.jar
-Dcom.sun.aas.classloader.optionalOverrideableChain.ee=
-Dcom.sun.aas.classloader.optionalOverrideableChain=webservices-rt.jar,webservices-tools.jar
-Dcom.sun.aas.classloader.serverClassPath.ee=/lib/hadbjdbc4.jar,/home/haug/programs/glassfish-v2-b58g/lib/SUNWjdmk/5.1/lib/jdmkrt.jar,/lib/dbstate.jar,/lib/hadbm.jar,/lib/hadbmgt.jar,/opt/sun/mfwk/share/lib/mfwk_instrum_tk.jar
-Dcom.sun.aas.classloader.serverClassPath=/home/haug/programs/glassfish-v2-b58g/lib/install/applications/jmsra/imqjmsra.jar,/home/haug/programs/glassfish-v2-b58g/imq/lib/jaxm-api.jar,/home/haug/programs/glassfish-v2-b58g/imq/lib/fscontext.jar,/home/haug/programs/glassfish-v2-b58g/imq/lib/imqbroker.jar,/home/haug/programs/glassfish-v2-b58g/imq/lib/imqjmx.jar,/home/haug/programs/glassfish-v2-b58g/lib/ant/lib/ant.jar,/home/haug/programs/glassfish-v2-b58g/lib/SUNWjdmk/5.1/lib/jdmkrt.jar
-Dcom.sun.aas.classloader.sharedChainJars.ee=appserv-se.jar,appserv-ee.jar,jesmf-plugin.jar,/lib/dbstate.jar,/lib/hadbjdbc4.jar,jgroups-all.jar,/opt/sun/mfwk/share/lib/mfwk_instrum_tk.jar
-Dcom.sun.aas.classloader.sharedChainJars=javaee.jar,/opt/java/jdk1.6.0/lib/tools.jar,install/applications/jmsra/imqjmsra.jar,com-sun-commons-launcher.jar,com-sun-commons-logging.jar,/home/haug/programs/glassfish-v2-b58g/imq/lib/jaxm-api.jar,/home/haug/programs/glassfish-v2-b58g/imq/lib/fscontext.jar,/home/haug/programs/glassfish-v2-b58g/imq/lib/imqbroker.jar,/home/haug/programs/glassfish-v2-b58g/imq/lib/imqjmx.jar,/home/haug/programs/glassfish-v2-b58g/imq/lib/imqxm.jar,webservices-rt.jar,webservices-tools.jar,mail.jar,appserv-jstl.jar,jmxremote_optional.jar,/home/haug/programs/glassfish-v2-b58g/lib/SUNWjdmk/5.1/lib/jdmkrt.jar,activation.jar,appserv-rt.jar,appserv-admin.jar,appserv-cmp.jar,/home/haug/programs/glassfish-v2-b58g/updatecenter/lib/updatecenter.jar,/home/haug/programs/glassfish-v2-b58g/jbi/lib/jbi.jar,/home/haug/programs/glassfish-v2-b58g/imq/lib/imqjmx.jar,/home/haug/programs/glassfish-v2-b58g/lib/ant/lib/ant.jar,dbschema.jar
-Dcom.sun.aas.configName=server-config
-Dcom.sun.aas.configRoot=/home/haug/programs/glassfish-v2-b58g/config
-Dcom.sun.aas.defaultLogFile=/home/haug/programs/glassfish-v2-b58g/domains/domain1/logs/server.log
-Dcom.sun.aas.domainName=domain1
-Dcom.sun.aas.installRoot=/home/haug/programs/glassfish-v2-b58g
-Dcom.sun.aas.instanceName=server
-Dcom.sun.aas.processLauncher=SE
-Dcom.sun.aas.promptForIdentity=true
-Dcom.sun.enterprise.config.config_environment_factory_class=com.sun.enterprise.config.serverbeans.AppserverConfigEnvironmentFactory
-Dcom.sun.enterprise.overrideablejavaxpackages=javax.help,javax.portlet
-Dcom.sun.enterprise.taglibs=appserv-jstl.jar,jsf-impl.jar
-Dcom.sun.enterprise.taglisteners=jsf-impl.jar
-Dcom.sun.updatecenter.home=/home/haug/programs/glassfish-v2-b58g/updatecenter
-Ddomain.name=domain1
-Dhttp.nonProxyHosts=[localhost|127.0.0.0/8|localhost|127.0.0.1|zesi
-Dhttp.proxyHost=localhost
-Dhttp.proxyPort=3128
-Dhttps.proxyHost=localhost
-Dhttps.proxyPort=3128
-Djava.endorsed.dirs=/home/haug/programs/glassfish-v2-b58g/lib/endorsed
-Djava.ext.dirs=/opt/java/jdk1.6.0/lib/ext:/opt/java/jdk1.6.0/jre/lib/ext:/home/haug/programs/glassfish-v2-b58g/domains/domain1/lib/ext:/home/haug/programs/glassfish-v2-b58g/javadb/lib
-Djava.library.path=/home/haug/programs/glassfish-v2-b58g/lib:/home/haug/programs/glassfish-v2-b58g/lib:/home/haug/programs/glassfish-v2-b58g/lib
-Djava.security.auth.login.config=/home/haug/programs/glassfish-v2-b58g/domains/domain1/config/login.conf
-Djava.security.policy=/home/haug/programs/glassfish-v2-b58g/domains/domain1/config/server.policy
-Djava.util.logging.manager=com.sun.enterprise.server.logging.ServerLogManager
-Djavax.management.builder.initial=com.sun.enterprise.admin.server.core.jmx.AppServerMBeanServerBuilder
-Djavax.net.ssl.keyStore=/home/haug/programs/glassfish-v2-b58g/domains/domain1/config/keystore.jks
-Djavax.net.ssl.trustStore=/home/haug/programs/glassfish-v2-b58g/domains/domain1/config/cacerts.jks
-Djdbc.drivers=org.apache.derby.jdbc.ClientDriver
-Djmx.invoke.getters=true
-Dsun.rmi.dgc.client.gcInterval=3600000
-Dsun.rmi.dgc.server.gcInterval=3600000
-client
-XX:+UnlockDiagnosticVMOptions
-XX:MaxPermSize=192m
-Xmx512m
-XX:NewRatio=2
-XX:+LogVMOutput
-XX:LogFile=/home/haug/programs/glassfish-v2-b58g/domains/domain1/logs/jvm.log
-cp
/home/haug/programs/glassfish-v2-b58g/lib/jhall.jar:/home/haug/programs/glassfish-v2-b58g/lib/appserv-launch.jar
com.sun.enterprise.server.PELaunch
start
Starting Sun Java System Application Server 9.1 (build b58g-fcs) ...
MBeanServer started: com.sun.enterprise.interceptor.DynamicInterceptor
CORE5098: AS Socket Service Initialization has been completed.
CORE5076: Using [Java HotSpot(TM) Client VM, Version 1.6.0_01] from [Sun Microsystems Inc.]
SEC1002: Security Manager is OFF.
/home/haug/programs/glassfish-v2-b58g/domains/domain1/config/.__com_sun_appserv_pid
ADM0001:SunoneInterceptor is now enabled
SEC1143: Loading policy provider com.sun.enterprise.security.provider.PolicyWrapper.
WEB0114: SSO is disabled in virtual server [server]
WEB0114: SSO is disabled in virtual server [__asadmin]
ADM1079: Initialization of AMX MBeans started
ADM1504: Here is the JMXServiceURL for the Standard JMXConnectorServer: [service:jmx:rmi:///jndi/rmi://localhost.localdomain:8686/jmxrmi]. This is where the remote administrative clients should connect using the standard JMX connectors
ADM1506: Status of Standard JMX Connector: Active = [true]
[AutoDeploy] Selecting file /home/haug/programs/glassfish-v2-b58g/lib/install/applications/__ejb_container_timer_app.ear for autodeployment.
deployed with moduleid = __ejb_container_timer_app
[AutoDeploy] Successfully autodeployed : /home/haug/programs/glassfish-v2-b58g/lib/install/applications/__ejb_container_timer_app.ear.
[AutoDeploy] Selecting file /home/haug/programs/glassfish-v2-b58g/lib/install/applications/__JWSappclients.ear for autodeployment.
deployed with moduleid = __JWSappclients
[AutoDeploy] Successfully autodeployed : /home/haug/programs/glassfish-v2-b58g/lib/install/applications/__JWSappclients.ear.
[AutoDeploy] Selecting file /home/haug/programs/glassfish-v2-b58g/lib/install/applications/MEjbApp.ear for autodeployment.
deployed with moduleid = MEjbApp
[AutoDeploy] Successfully autodeployed : /home/haug/programs/glassfish-v2-b58g/lib/install/applications/MEjbApp.ear.
JBIFW0010: JBI framework ready to accept requests.
WEB0302: Starting Sun-Java-System/Application-Server.
No Principals mapped to Role [noaccess].
WEB0712: Starting Sun-Java-System/Application-Server HTTP/1.1 on 8080
WEB0712: Starting Sun-Java-System/Application-Server HTTP/1.1 on 8181
WEB0712: Starting Sun-Java-System/Application-Server HTTP/1.1 on 4848
SMGT0007: Self Management Rules service is enabled
Application server startup complete.
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 3, 2007 11:31 AM
in response to: John Clingan
|
|
|
I would agree with previous request.
Application Version
It helps during deployment to reduce down time and if we can also access to different version of code through which QA work can be completed would be great. This may give great flexibility
Configuration Version
Trouble shooting & Diagnosing a problem
Improve the logging and add some standard ways to capture runtime snapshot which can be used for later analysis. Walking through some common problem scenarios and improving the mean time to repair will be very useful feature.
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 4, 2007 1:52 PM
in response to: John Clingan
|
|
|
one word: OSGi
(desperately needed since Sun doesn't manage to fix annoying Java-issues)
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 4, 2007 4:37 PM
in response to: mystermask
|
|
|
Hi mystermask...
Can you expand on what you want to achieve from adding OSGi support?
You can go look at the comments at [1] for a useful exchange.
[1]http://blogs.sun.com/theaquarium/entry/glassfish_v3_themes_and_what
THanks,
- eduard/o
glassfish@javadesktop.org wrote:
> one word: OSGi
> (desperately needed since Sun doesn't manage to fix annoying Java-issues)
> [Message sent by forum member 'mystermask' (mystermask)]
>
> http://forums.java.net/jive/thread.jspa?messageID=243717
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 4, 2007 5:42 PM
in response to: John Clingan
|
|
|
I think it would be nice if GF implemented classic web server facilities better so as to make GF an easier replacement for a web server. So that folks don't have to choose between, or use both, GF and Apache for most common applications.
Notably things like url rewriting, simple proxy duties, CGI/FastCGI so that folks could easily add PHP and what not behind GF. All managed via the Console, of course.
Some of this is possible today, but none of it is readily exposed by the console.
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 4, 2007 11:08 PM
in response to: whartung
|
|
|
I agree with that. Another reason for making GF a better webfront is to be able to use a stripped-down version as the web-load balancer and not have to manage a separate beast for that. If it is as the grizzly gang suggests that there is now no appreciable difference from a performance perspective between Grizzly and a native web server, such as Apache httpd or Sun Webserver.
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 5, 2007 6:54 AM
in response to: whartung
|
|
|
glassfish@javadesktop.org wrote:
> I think it would be nice if GF implemented classic web server facilities better so as to make GF an easier replacement for a web server. So that folks don't have to choose between, or use both, GF and Apache for most common applications.
>
> Notably things like url rewriting, simple proxy duties, CGI/FastCGI so that folks could easily add PHP and what not behind GF. All managed via the Console, of course.
>
FastCGI and PHP are planned for v3:
http://wiki.glassfish.java.net/Wiki.jsp?page=V3WebTier
-- Jeanfrancois
> Some of this is possible today, but none of it is readily exposed by the console.
> [Message sent by forum member 'whartung' (whartung)]
>
> http://forums.java.net/jive/thread.jspa?messageID=243737
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
|
|
|
|
|
Re: Other links on feedback -- Re: GlassFish V3 planning - What do *you*
Posted:
Nov 5, 2007 5:32 PM
in response to: Eduardo Pelegri...
|
|
|
Thanks Eduardo! Trying to get caught up. Lots of very good feedback. However, I'd still like to get a community call together so we can double-click on some of these requirements to better understand them.
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 5, 2007 2:26 AM
in response to: John Clingan
|
|
|
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.
- 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. Application versioning (also mentioned before) for a fallback scenario.
- 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).
- 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.
- 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.
- 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).
That's about it 
greets
jeremie
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 5, 2007 2:52 AM
in response to: granat
|
|
|
I couldn't agree more to the last point, it should be easy and user friendly to configure the modules for use or exclusion. We don't want to go down the JBoss route that everything is possible if you can find the right permutation of files and XML-elements to modify to "break-apart" stuff or configure the container. If that is the price of modularity, I'm not sure it's worth it.
- Singleton service sounds interesting as well, it opens up a few possibilities that I hadn't thought of.
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 5, 2007 7:21 AM
in response to: granat
|
|
|
I forgot:
- I'd also like the possibility to log to a database. This features would work like this: A database connection (datasource) is defined and the logger in a defined configuration is linked to it. This would make it available for multiple servers all logging to the database (a way should be found for if the database connection is lost). A GUI should also be avalable to access the log of the database and do some filtering. A system like that would allow an easier access to logs written by clustered applications where one has to check all logs of all machine to see where an error has happened.
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 5, 2007 5:50 PM
in response to: granat
|
|
|
> 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
> greets
> jeremie
Great feedback, jeremie. Thanks!
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 6, 2007 1:27 AM
in response to: jclingan
|
|
|
> > 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
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
> > greets
> > jeremie
>
> Great feedback, jeremie. Thanks!
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 5, 2007 7:38 AM
in response to: John Clingan
|
|
|
Isn't there an issue about the size of the jars needed by Java Web Start clients of EJB3 beans. Would be nice to see improvements in a similar vein as the streamlining/simplification going on with the Consumer JRE and with JavaFX.
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 5, 2007 7:47 AM
in response to: osbald
|
|
|
glassfish@javadesktop.org wrote:
> Isn't there an issue about the size of the jars needed by Java Web Start clients of EJB3 beans. Would be nice to see improvements in a similar vein as the streamlining/simplification going on with the Consumer JRE and with JavaFX.
Indeed there is, and it's been written about extensively and improving
this is very high on our list for V3. It's actually an issue whether
the client is launched using Java Web Start or not, but it's definitely
more visible that way.
We will not be able to take full advantage the improvements coming in
the JRE because V3 won't be able to assume a suitably advanced JRE.
Having said that, the modular approach that permeates V3 will drive this
improvement in the client to reduce the number and size of JARs needed.
- Tim
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 5, 2007 8:09 AM
in response to: Tim Quinn
|
|
|
How hard would it be to have a JRE-client specific configuration? It
would seem to me that some deployments will be (maybe very large)
intranet with strong requirements on the clients' configurations, so
some customers may be willing to force their desktops to upgrade.
Would need validation of user's requriements, of course....
Tim Quinn wrote:
>
>
> glassfish@javadesktop.org wrote:
>> Isn't there an issue about the size of the jars needed by Java Web
>> Start clients of EJB3 beans. Would be nice to see improvements in a
>> similar vein as the streamlining/simplification going on with the
>> Consumer JRE and with JavaFX.
> Indeed there is, and it's been written about extensively and improving
> this is very high on our list for V3. It's actually an issue whether
> the client is launched using Java Web Start or not, but it's definitely
> more visible that way.
>
> We will not be able to take full advantage the improvements coming in
> the JRE because V3 won't be able to assume a suitably advanced JRE.
> Having said that, the modular approach that permeates V3 will drive this
> improvement in the client to reduce the number and size of JARs needed.
>
> - Tim
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 5, 2007 9:11 AM
in response to: Eduardo Pelegri...
|
|
|
Eduardo Pelegri-Llopart wrote:
> How hard would it be to have a JRE-client specific configuration? It
> would seem to me that some deployments will be (maybe very large)
> intranet with strong requirements on the clients' configurations, so
> some customers may be willing to force their desktops to upgrade.
I expect we will encourage users to choose which JRE release to use with
several things in mind (see below). I don't think GlassFish itself will
need to be built or configured differently to take advantage of new and
coming improvements in the JRE.
1. I was intrigued by the possibility of using the Java kernel (Consumer
JRE) technology in GlassFish itself, especially for the app client
container. So I wrote to the folks working on the Java kernel effort.
They have not now - nor do they plan to - expose or support that
technology for use by developers for their own apps, even system apps
like app servers. The implementation was described as quite specific to
the JRE itself. They are advising people to wait for the implementation
of JSR-277 - the Java Module System.
2. I expect we will make good strides in reducing the app client
container footprint (number and sizes of JAR files required) using the
V3 module technology. This will not only shrink the footprint but
should also give app clients the advantage of just-in-time module
loading into the JVM - just as the Java kernel work gives the JRE
itself. The V3 module technology will not in and of itself provide the
deferred download behavior, but...
3. A near-equivalent of the deferred download behavior should be there
for Java Web Start launches if, as I plan, we use JAR indexing for the
app client container JAR in GlassFish V3. Java Web Start in Java SE 6
takes full advantage of JAR indexing, postponing the download of any
referenced JAR until its contents are needed.
I'm not sure where we stand at the moment about the minimum Java SE
release we'll require for GlassFish V3. But even if we will not require
Java SE 6, the approach I've sketched above allows us to build the
GlassFish V3 app client container to take advantage of these advances in
JRE technology without requiring users to run a particular minimum
release of Java SE.
We would certainly advertise the benefits of using Java SE 6 if
end-users will launch app clients using the GlassFish Java Web Start
feature. And we would advertise the benefits of the Consumer JRE/Java
kernel technology for app clients as it becomes available. Then users
can choose the Java SE release (and the rollout plan in their
enterprise!) that makes sense for them.
- Tim
>
> Would need validation of user's requriements, of course....
>
> Tim Quinn wrote:
>>
>>
>> glassfish@javadesktop.org wrote:
>>> Isn't there an issue about the size of the jars needed by Java Web
>>> Start clients of EJB3 beans. Would be nice to see improvements in a
>>> similar vein as the streamlining/simplification going on with the
>>> Consumer JRE and with JavaFX.
>> Indeed there is, and it's been written about extensively and
>> improving this is very high on our list for V3. It's actually an
>> issue whether the client is launched using Java Web Start or not, but
>> it's definitely more visible that way.
>>
>> We will not be able to take full advantage the improvements coming in
>> the JRE because V3 won't be able to assume a suitably advanced JRE.
>> Having said that, the modular approach that permeates V3 will drive
>> this improvement in the client to reduce the number and size of JARs
>> needed.
>>
>> - Tim
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
>> For additional commands, e-mail: users-help@glassfish.dev.java.net
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
|
|
RE: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 5, 2007 9:36 AM
in response to: Tim Quinn
|
|
|
I don't know if this is worth anything but I would like to see some form of UDDI or Web Service discovery directory implementation if at all possible.
________________
Thanks and regards
Kenneth Clark
Solutions Engineer
Tel: 27 11 679 3075
Mobile: 27 (0) 84 583 1348
Email: kenneth.clark@skyetech.co.za
Website: http://www.skyetech.co.za
-----Original Message-----
From: Timothy.Quinn@Sun.COM [mailto:Timothy.Quinn@Sun.COM]
Sent: 05 November 2007 19:12
To: users@glassfish.dev.java.net
Subject: Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Eduardo Pelegri-Llopart wrote:
> How hard would it be to have a JRE-client specific configuration? It
> would seem to me that some deployments will be (maybe very large)
> intranet with strong requirements on the clients' configurations, so
> some customers may be willing to force their desktops to upgrade.
I expect we will encourage users to choose which JRE release to use with
several things in mind (see below). I don't think GlassFish itself will
need to be built or configured differently to take advantage of new and
coming improvements in the JRE.
1. I was intrigued by the possibility of using the Java kernel (Consumer
JRE) technology in GlassFish itself, especially for the app client
container. So I wrote to the folks working on the Java kernel effort.
They have not now - nor do they plan to - expose or support that
technology for use by developers for their own apps, even system apps
like app servers. The implementation was described as quite specific to
the JRE itself. They are advising people to wait for the implementation
of JSR-277 - the Java Module System.
2. I expect we will make good strides in reducing the app client
container footprint (number and sizes of JAR files required) using the
V3 module technology. This will not only shrink the footprint but
should also give app clients the advantage of just-in-time module
loading into the JVM - just as the Java kernel work gives the JRE
itself. The V3 module technology will not in and of itself provide the
deferred download behavior, but...
3. A near-equivalent of the deferred download behavior should be there
for Java Web Start launches if, as I plan, we use JAR indexing for the
app client container JAR in GlassFish V3. Java Web Start in Java SE 6
takes full advantage of JAR indexing, postponing the download of any
referenced JAR until its contents are needed.
I'm not sure where we stand at the moment about the minimum Java SE
release we'll require for GlassFish V3. But even if we will not require
Java SE 6, the approach I've sketched above allows us to build the
GlassFish V3 app client container to take advantage of these advances in
JRE technology without requiring users to run a particular minimum
release of Java SE.
We would certainly advertise the benefits of using Java SE 6 if
end-users will launch app clients using the GlassFish Java Web Start
feature. And we would advertise the benefits of the Consumer JRE/Java
kernel technology for app clients as it becomes available. Then users
can choose the Java SE release (and the rollout plan in their
enterprise!) that makes sense for them.
- Tim
>
> Would need validation of user's requriements, of course....
>
> Tim Quinn wrote:
>>
>>
>> glassfish@javadesktop.org wrote:
>>> Isn't there an issue about the size of the jars needed by Java Web
>>> Start clients of EJB3 beans. Would be nice to see improvements in a
>>> similar vein as the streamlining/simplification going on with the
>>> Consumer JRE and with JavaFX.
>> Indeed there is, and it's been written about extensively and
>> improving this is very high on our list for V3. It's actually an
>> issue whether the client is launched using Java Web Start or not, but
>> it's definitely more visible that way.
>>
>> We will not be able to take full advantage the improvements coming in
>> the JRE because V3 won't be able to assume a suitably advanced JRE.
>> Having said that, the modular approach that permeates V3 will drive
>> this improvement in the client to reduce the number and size of JARs
>> needed.
>>
>> - Tim
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
>> For additional commands, e-mail: users-help@glassfish.dev.java.net
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.503 / Virus Database: 269.15.22/1111 - Release Date: 2007/11/05 04:36
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.503 / Virus Database: 269.15.22/1111 - Release Date: 2007/11/05 04:36
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
|
|
Re: RE: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 6, 2007 12:44 PM
in response to: Kenneth Clark
|
|
|
+1 for UDDI, Service Repositories
|
|
|
|
|
|
|
|
|
Re: RE: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 6, 2007 1:57 PM
in response to: vemulapallikish...
|
|
|
These might be more like J2ee standards extension issues, but anyway:
I end up augmenting each .ear or .war I ship for deployment with a
small shell script which calls asadmin a few times to set up and test
JDBC connection pools. (to be honest, since I need to have this script
anyway, I just create the database and tables from here too, even
though I know TopLink could create them for me if I only asked. (not
sure about indexes though.))
So I'd like to see a method of packaging this kind of information
along with an .ear .
On the other hand some of the things in the web.xml and
persistence.xml strike me as if they would need to be specific to each
deployment, like init-params, or the existence of an optional
persistence unit.
So I'd like to see a method for simply and reliably manipulating, or
overriding such settings in the war.
And finally a big "me too" for application and configuration
versioning and rollback!
Oh, and our clients, often used to CISCO IOS and similar non-graphical
interfaces find the usability of asadmin somewhat lacking (tab
completion, context-sensitive help, etc.)
Gabor Szokoli
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
|
|
Re: RE: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 6, 2007 4:04 PM
in response to: Gabor Szokoli
|
|
|
I don't think that it'd have to be an extension to the JEE standards. The app-server specific deployment descriptors could contain resource defintions, basically snippets from the domain.xml to setup data sources, pools, destination factories, etc.
That could be a very convenient feature to simplify the deployments and really make it a one-step process.
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 26, 2007 11:08 AM
in response to: vemulapallikish...
|
|
|
Is the idea here to be a client to a service registry (deploy WSDL,
view registry, etc) or to include a service registry with GlassFish?
On Nov 6, 2007, at 12:44 PM, glassfish@javadesktop.org wrote:
> +1 for UDDI, Service Repositories
> [Message sent by forum member
> 'vemulapallikishore' (vemulapallikishore)]
>
> http://forums.java.net/jive/thread.jspa?messageID=244161
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 9, 2007 1:12 PM
in response to: Tim Quinn
|
|
|
-------------- Quick summary -------------------------
When using web start or the app client script I'd like to be able to include a
splash screen in the application-client.xml file that is passed as an argument
to the JRE.
-------------- The long winded version --------------
I'm a little late to this discussion, but I have a couple web start specific
observations. I've been using the web start functionality for a little while
and, besides the large download, there is one thing that would keep me from
using it in a production environment.
When I launch an application via web start, there is a delay, with no user
feedback or splash screen, while the acc loads.
With the client script download I can modify it and give the jre a splash screen
to use until my application takes over and can show a real, progress monitored,
splash screen. I use the same image for both and it looks like one splash
screen from the second you double click the app until the UI frame loads.
Tim Quinn wrote:
>
>
> Eduardo Pelegri-Llopart wrote:
>> How hard would it be to have a JRE-client specific configuration? It
>> would seem to me that some deployments will be (maybe very large)
>> intranet with strong requirements on the clients' configurations, so
>> some customers may be willing to force their desktops to upgrade.
> I expect we will encourage users to choose which JRE release to use with
> several things in mind (see below). I don't think GlassFish itself will
> need to be built or configured differently to take advantage of new and
> coming improvements in the JRE.
>
> 1. I was intrigued by the possibility of using the Java kernel (Consumer
> JRE) technology in GlassFish itself, especially for the app client
> container. So I wrote to the folks working on the Java kernel effort.
> They have not now - nor do they plan to - expose or support that
> technology for use by developers for their own apps, even system apps
> like app servers. The implementation was described as quite specific to
> the JRE itself. They are advising people to wait for the implementation
> of JSR-277 - the Java Module System.
> 2. I expect we will make good strides in reducing the app client
> container footprint (number and sizes of JAR files required) using the
> V3 module technology. This will not only shrink the footprint but
> should also give app clients the advantage of just-in-time module
> loading into the JVM - just as the Java kernel work gives the JRE
> itself. The V3 module technology will not in and of itself provide the
> deferred download behavior, but...
>
> 3. A near-equivalent of the deferred download behavior should be there
> for Java Web Start launches if, as I plan, we use JAR indexing for the
> app client container JAR in GlassFish V3. Java Web Start in Java SE 6
> takes full advantage of JAR indexing, postponing the download of any
> referenced JAR until its contents are needed.
> I'm not sure where we stand at the moment about the minimum Java SE
> release we'll require for GlassFish V3. But even if we will not require
> Java SE 6, the approach I've sketched above allows us to build the
> GlassFish V3 app client container to take advantage of these advances in
> JRE technology without requiring users to run a particular minimum
> release of Java SE.
> We would certainly advertise the benefits of using Java SE 6 if
> end-users will launch app clients using the GlassFish Java Web Start
> feature. And we would advertise the benefits of the Consumer JRE/Java
> kernel technology for app clients as it becomes available. Then users
> can choose the Java SE release (and the rollout plan in their
> enterprise!) that makes sense for them.
>
> - Tim
>
>
>>
>> Would need validation of user's requriements, of course....
>>
>> Tim Quinn wrote:
>>>
>>>
>>> glassfish@javadesktop.org wrote:
>>>> Isn't there an issue about the size of the jars needed by Java Web
>>>> Start clients of EJB3 beans. Would be nice to see improvements in a
>>>> similar vein as the streamlining/simplification going on with the
>>>> Consumer JRE and with JavaFX.
>>> Indeed there is, and it's been written about extensively and
>>> improving this is very high on our list for V3. It's actually an
>>> issue whether the client is launched using Java Web Start or not, but
>>> it's definitely more visible that way.
>>>
>>> We will not be able to take full advantage the improvements coming in
>>> the JRE because V3 won't be able to assume a suitably advanced JRE.
>>> Having said that, the modular approach that permeates V3 will drive
>>> this improvement in the client to reduce the number and size of JARs
>>> needed.
>>>
>>> - Tim
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
>>> For additional commands, e-mail: users-help@glassfish.dev.java.net
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
>> For additional commands, e-mail: users-help@glassfish.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 5, 2007 6:11 PM
in response to: John Clingan
|
|
|
I'd like to have a community meeting (conference call) to discuss requirements
in real-time. I'd like to get community feedback on the following
times and we'll pick a slot:
Thursday, Nov 8th @ 8:00am Pacific Time
Thursday, Nov 8th @ 5:00pm Pacific Time
Friday, Nov 9th @ 8:00am Pacific Time
Friday, Nov 9th @ 5:00pm Pacific Time
We can also try for mid-day, but I'm not sure how that will work for
folks over-seas.
Please RSVP to this thread with features you would like to discuss in
more depth (Sun & non-Sun folks alike). If we get a lot of feedback
we'll schedule followup calls and perhaps break them down by topic.
I'll send out the call-in information in a subsequent post when we
narrow down a time slot.
Thanks!
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 6, 2007 12:38 PM
in response to: jclingan
|
|
|
I am looking for the following.
1. Application Versions (like others have requested).
2. Work flows, both Systems and human interaction (I see some work on BPEL and Worklist Management SE in OpenESB. Or may be JSR-207 Process Definition for Java / BPELJ . Ease of use, align with Java EE)
3. SCA (& SDO?) for SOA and align with Java EE
4. Rule engine based on jsr-94
5. Content Management
6. Portlets / Portals - JSR-286, JSR-301
7. More realtime monotoring capabilities using JMX.
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 6, 2007 1:40 PM
in response to: jclingan
|
|
|
I don't know which of these would work best for me, but I'd try and be on the call.
5pm Friday would be right out tho
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 6, 2007 8:18 AM
in response to: John Clingan
|
|
|
Would it be possible to have a Maven 2 Plugin, similar to the Jetty Plugin? It's really handy when writing apps, as I don't have to redeploy as I develop. It would be neat to add Maven 2 POM files to the list of available build mechanisms ( I could help with this if you'd like), and maybe help with the Glassfish plugin development for Maven 2 as well if it is something that would be of interest.
Thanks,
Jim
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 6, 2007 11:50 AM
in response to: jimbethancourt
|
|
|
Yes, we are addressing this issue. In the Maven VM, we will load GlassFish runtime that
runs your application.
- Kedar
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 7, 2007 9:48 PM
in response to: km
|
|
|
hello,
Support for terracotta.
It would greatly increase current asynchron session replication performance and also allow for good performing synchron replication, that today is a missing feature due to performance problems..
Terracotta in GF is currently stopped by the fact that GF relies on a custom branch of tomcat that does not allow for terracotta to hook itself in.¨:
http://www.terracotta.org/confluence/display/docs1/Integrations+Glassfish
Perhaps by using terracotta , or at least allowing it to plug in could allow for good synchronized replication performce in V2.1 or V3 ?
regards
gustav trede
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 8, 2007 9:39 AM
in response to: gustav3d
|
|
|
Hi Gustav3d -- We would very much welcome Terracotta working with us to
integrate into GlassFish. We had an early proof of concept a while ago,
for JavaOne but we have been busy on both sides since then. Please let
your contacts at Terracotta know of your interest and we will work on
our side to do the same.
- eduard/o
glassfish@javadesktop.org wrote:
> hello,
>
> Support for terracotta.
> It would greatly increase current asynchron session replication performance and also allow for good performing synchron replication, that today is a missing feature due to performance problems..
>
>
> Terracotta in GF is currently stopped by the fact that GF relies on a custom branch of tomcat that does not allow for terracotta to hook itself in.¨:
> http://www.terracotta.org/confluence/display/docs1/Integrations+Glassfish
>
> Perhaps by using terracotta , or at least allowing it to plug in could allow for good synchronized replication performce in V2.1 or V3 ?
>
>
> regards
> gustav trede
> [Message sent by forum member 'gustav3d' (gustav3d)]
>
> http://forums.java.net/jive/thread.jspa?messageID=244459
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 8, 2007 10:49 AM
in response to: Eduardo Pelegri...
|
|
|
Eduardo Pelegri-Llopart wrote:
> Hi Gustav3d -- We would very much welcome Terracotta working with us to
> integrate into GlassFish. We had an early proof of concept a while ago,
> for JavaOne but we have been busy on both sides since then. Please let
> your contacts at Terracotta know of your interest and we will work on
> our side to do the same.
The fix is quite simple and I already talked to them I guess they
worried about to have two implementations to maintains because we forked
from Tomcat (but our Valve implementation perform better, so we should
convince them this is the way to go :-)).
-- Jeanfrancois
>
> - eduard/o
>
> glassfish@javadesktop.org wrote:
>> hello,
>>
>> Support for terracotta. It would greatly increase current asynchron
>> session replication performance and also allow for good performing
>> synchron replication, that today is a missing feature due to
>> performance problems..
>>
>>
>> Terracotta in GF is currently stopped by the fact that GF relies on a
>> custom branch of tomcat that does not allow for terracotta to hook
>> itself in.¨:
>> http://www.terracotta.org/confluence/display/docs1/Integrations+Glassfish
>>
>> Perhaps by using terracotta , or at least allowing it to plug in could
>> allow for good synchronized replication performce in V2.1 or V3 ?
>>
>> regards
>> gustav trede
>> [Message sent by forum member 'gustav3d' (gustav3d)]
>>
>> http://forums.java.net/jive/thread.jspa?messageID=244459
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
>> For additional commands, e-mail: users-help@glassfish.dev.java.net
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 8, 2007 7:50 AM
in response to: John Clingan
|
|
|
---->Performance<----
I see a lot of good things in GF2 and would like to try out the clustering features on some small machines.
Right now many parallel jvm instances are needed each needing a rather high heap size..
In GF2 it seems, correct me if I'm wrong, like the server either runs like an engine or not at all...
For platform testing, small J2EE applications and student projects it would be nice if small machines could run GF at the expense of slower performance of course.
--->Easier installation<---
To continue from my last point being able to get the server to start working is fundamental for further evaluation of GF as platform.
I hope future releases of GF will make friends with the OS, like be able to read or setup the hosts file, environmental variables etc.
--->J6EE reference server<---
I really look forward to check out the next enterprise edition, and I hope that the new specifications will be implemented quickly.
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 8, 2007 9:50 AM
in response to: slingblade
|
|
|
Where i can find which items of this thread is approved for implementation ?
Is there any place that all feature mentioned in the thread were listed?
Thanks
glassfish@javadesktop.org wrote:
> ---->Performance<----
> I see a lot of good things in GF2 and would like to try out the clustering features on some small machines.
>
> Right now many parallel jvm instances are needed each needing a rather high heap size..
>
> In GF2 it seems, correct me if I'm wrong, like the server either runs like an engine or not at all...
>
> For platform testing, small J2EE applications and student projects it would be nice if small machines could run GF at the expense of slower performance of course.
>
> --->Easier installation<---
> To continue from my last point being able to get the server to start working is fundamental for further evaluation of GF as platform.
>
> I hope future releases of GF will make friends with the OS, like be able to read or setup the hosts file, environmental variables etc.
>
> --->J6EE reference server<---
> I really look forward to check out the next enterprise edition, and I hope that the new specifications will be implemented quickly.
> [Message sent by forum member 'slingblade' (slingblade)]
>
> http://forums.java.net/jive/thread.jspa?messageID=244545
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 8, 2007 10:01 AM
in response to: legolas wood
|
|
|
I would hope that the requests being entered into the various "what do
you want" threads would get captured as ENHANCEMENT issues in the issue
tracker and assigned to some product manager, "boss", architect,
whatever to evaluate, prioritize and delegate to folks to design and
implement.
Most of the issue tracker stuff currently gets assigned to line
engineers by default... This is great for bugs... but it is a poor
strategy for enhancement requests.
Hopefully, John Clingan... who started this thread is already doing this.
vbk
legolas wood wrote:
> Where i can find which items of this thread is approved for
> implementation ?
> Is there any place that all feature mentioned in the thread were listed?
>
> Thanks
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 8, 2007 4:18 PM
in response to: Vince Kraemer
|
|
|
I am tracking these. Many will pop up in the GlassFish V3 requirements
wiki page I am about to create. These requests are not being lost.
On Nov 8, 2007, at 10:01 AM, Vince Kraemer wrote:
> I would hope that the requests being entered into the various "what
> do you want" threads would get captured as ENHANCEMENT issues in the
> issue tracker and assigned to some product manager, "boss",
> architect, whatever to evaluate, prioritize and delegate to folks to
> design and implement.
>
> Most of the issue tracker stuff currently gets assigned to line
> engineers by default... This is great for bugs... but it is a poor
> strategy for enhancement requests.
>
> Hopefully, John Clingan... who started this thread is already doing
> this.
>
> vbk
>
> legolas wood wrote:
>> Where i can find which items of this thread is approved for
>> implementation ?
>> Is there any place that all feature mentioned in the thread were
>> listed?
>>
>> Thanks
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 9, 2007 1:10 AM
in response to: John Clingan
|
|
|
FYI, we are starting to capture GlassFish V3 feature requests in the GlassFish wiki. Note, some of the requests in this thread have been captured, others are in-process of being captured. Please bear with us as we are in the early stages of building the requirements. If you don't see something there you want (that hasn't been mentioned in this thread), want clarification on an issue, etc, please start a thread or comment on the wiki pages using comment link) to start discussion.
http://wiki.glassfish.java.net/Wiki.jsp?page=GlassFishV3Requirements
Thanks for the contributions to date. *VERY* good feedback.
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 10, 2007 10:38 AM
in response to: John Clingan
|
|
|
Some ideas:
1) EAR installation packages - There are a lot things that has to be done before an ear installation (JDBC/JMS pools, resources, adapter installation and configuration etc.). It's a quit complex task for server administrator. It would be helpful if developer could prepare installation package which would do all necessary tasks. Some tasks are dependent on current state of app. server so installation engine for EARs should be scriptable through package.
2) Deployment descriptor editing in web console.
3) Web Admin Console plugins - web console should be extensible with third party plugins
4) Scheduler - App server should support to define tasks/jobs implemented as EJB components. This should be administrable through console.
Sorry for my English
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 10, 2007 3:47 PM
in response to: gepard
|
|
|
> Some ideas:
>
> 1) EAR installation packages - There are a lot
> things that has to be done before an ear
> installation (JDBC/JMS pools, resources, adapter
> installation and configuration etc.). It's a quit
> complex task for server administrator. It would be
> helpful if developer could prepare installation
> package which would do all necessary tasks. Some
> tasks are dependent on current state of app. server
> so installation engine for EARs should be scriptable
> through package.
NetBeans kinda sorta does this already, so maybe some code can be lifted from there.
>
> 2) Deployment descriptor editing in web console.
>
> 3) Web Admin Console plugins - web console should be
> extensible with third party plugins
I would certainly like to see this. It would be nice to be able to integrate application administration aspect with the GF console...this gives a more "embedded" view when the application is distributed as a "whole" rather than as "Glassfish and the app". I think this is particularly important with v3's more component nature, and I think GF may be embedded more (at least components of it) because of it.
> 4) Scheduler - App server should support to define
> tasks/jobs implemented as EJB components. This should
> be administrable through console.
Probably best to wait for EJB 3.1 for this, but it's a good idea to at least be able to monitor scheduled jobs waiting in the container so the admin can hold them or stop them before they run. We can't do much once they're running (without a cooperating job), but it would be nice to be able to monitor them through the container.
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 26, 2007 11:06 AM
in response to: whartung
|
|
|
> > 4) Scheduler - App server should support to define
> > tasks/jobs implemented as EJB components. This
> should
> > be administrable through console.
>
> Probably best to wait for EJB 3.1 for this, but it's
> a good idea to at least be able to monitor scheduled
> jobs waiting in the container so the admin can hold
> them or stop them before they run. We can't do much
> once they're running (without a cooperating job), but
> it would be nice to be able to monitor them through
> the container.
Can either one of you give an example or use case. More detail here would really help. Thanks.
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 10, 2007 1:57 PM
in response to: John Clingan
|
|
|
On 10/30/07, John Clingan <John.Clingan@sun.com> wrote:
> If you have ideas of features or enhancements that you want in
> GlassFish V3, read on!
Here's my list - I'm a sysadmin, not a developer.
The #1 thing I want is flexibility, which is already on the way with h2k2.
That will be a boon to us, as we don't touch EJB at all but could really use
a nice fast web container with strong clustering support.
#2 is to play nice with others - I've had to abandon a planned GF deployment
because the JSF implementation clashed with some older webapps bundled
versions,
for example. I'm using off the shelf webapps and don't have the time
or skills to hack on
them extensively.
It's nice to have cutting edge features, but without backwards compatibility
it's hard for those of us who would like to drop in a 'better tomcat' for our
existing deployments.
#3 would be monitoring - good logging, maybe some DTrace etc support on
the relevant platforms.
When those apps fail to deploy, anything that helps me drill down to find what
JNDI resource it's asking for (or more often what Tomcat/JBoss specific
non-standard convention it's using) is a big help.
--
Rasputnik :: Jack of All Trades - Master of Nuns
http://number9.hellooperator.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 11, 2007 11:11 AM
in response to: John Clingan
|
|
|
Is embedded glassfish EJB3 container already available?
Supposed that my-test-client-entry.jar, my-test-ejbs.jar and all necessary metadata were built against EJB3 and i would run everything in a single JVM, could i deal with it simply calling something like "java -cp my-test-client-entry.jar:my-test-ejbs.jar:glassfish-ejb****.jar:other****.jar MyTestClientMain"?
Message was edited by: glassfisher
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 12, 2007 10:05 AM
in response to: glassfisher
|
|
|
On Nov 11, 2007, at 11:11 AM, glassfish@javadesktop.org wrote:
> Is embedded glassfish EJB3 container already available?
no it's not available yet
>
>
> Supposed that my-test-client-entry.jar, my-test-ejbs.jar and all
> necessary metadata were built against EJB3 and i would run
> everything in a single JVM, could i deal with it simply calling
> something like "java -cp my-test-client-entry.jar:my-test-
> ejbs.jar:glassfish-ejb****.jar:other****.jar"?
I am not sure what is the my-test-client-entry.jar component model ?
is it an appclient, just a plain java application ?
when we will have the ejb container working on v3, you will just need
to do something like
java -jar glassfish.jar my-test-ejbs.jar
to run your ejb bundle, I am not sure about your test clients however,
can you elaborate how these would be invoked ?
thx
>
> [Message sent by forum member 'glassfisher' (glassfisher)]
>
> http://forums.java.net/jive/thread.jspa?messageID=244958
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 12, 2007 1:52 PM
in response to: John Clingan
|
|
|
Thx!!! Great knowing GF-V3 will implement the feature exactly as i wished.
The test package my-ejb-test.jar consists of the following structure,
my-ejb-test
+client
-MyClientMain.class(standalone)
+model
-MyEntity.class
+service
-MyService.class
+stateless
-MyStateless.class
+stateful
-MyStateful.class
+META-INF
-ejb-jar.xml
-persistence.xml
So hopefully a quick test against EJB3 would succeed just calling "java -cp glassfish.jar my-ejb-test.jar" as you exactly said.
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 12, 2007 8:45 PM
in response to: glassfisher
|
|
|
sorry I think i did not clearly express my question.
it's more the content of my-test-client-entry.jar that I am interested
in. I understood that my-ejb-test.jar was an ejb bundle and you
therefore run it as specified below. but how do you plan to run my-
test-client-entry.jar ?
thx
On Nov 12, 2007, at 1:52 PM, glassfish@javadesktop.org wrote:
> Thx!!! Great knowing GF-V3 will implement the feature exactly as i
> wished.
>
> The test package my-ejb-test.jar consists of the following structure,
>
> my-ejb-test
> +client
> -MyClientMain.class(standalone)
> +model
> -MyEntity.class
> +service
> -MyService.class
> +stateless
> -MyStateless.class
> +stateful
> -MyStateful.class
> +META-INF
> -ejb-jar.xml
> -persistence.xml
>
> So hopefully a quick test against EJB3 would succeed just calling
> "java -cp glassfish.jar my-ejb-test.jar" as you exactly said.
> [Message sent by forum member 'glassfisher' (glassfisher)]
>
> http://forums.java.net/jive/thread.jspa?messageID=245117
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 14, 2007 1:30 AM
in response to: John Clingan
|
|
|
Hi there,
Hope I'm not too late to the party here, but some tidbits that I
collected recently.. some of these have been mentioned here and I just
want to second those.
-Maven support (run embedded, have plugins for deployment)
It would seem this already made the list
-More fine grained control over (session) bean lifecycle, pooling and caching
Correct me if I'm wrong, but it seems you can only control the total pool sizes.
I'd like to be able to make a bigger pool of session beans that are
known to be lighter and a smaller pool of certain utility and heavier
beans to better tune how the system is loaded.
We currently don't have any issues but it might be useful to allow fine tuning.
-Keep improving error messages and error handling.
Glassfish is going great in this department, keep at it as it helps me
track down errors better.
-Modules to replace Toplink by Hibernate
Modules seem to be the new direction that Glassfish is taking and we
would appreciate an easy to way to allow other implementations of JPA
in.
-Allow the creation of Unit tests for EJB's by making an embedded
Glassfish, much like embedded JBoss
We unit test our EJB's using JBoss embedded (both to ensure our
application stays honest and to have complete testing in our build)
Currently we have to use JBoss embedded... having a Glassfish version
is already listed in here and I can strongly second this
-Keep working on the module/application installer, maybe integration
within the admin interface would be nice.
Glassfish comes with a small Java app to install extra's like portals etc.
This is great and I hope to see this functionality inside the admin interface.
Smack me if this is already implemented or listed please
-While Glassfish will promote the use HK2, please make sure that those
using OSGi within their applications will not be impacted too severely
(IE try to keep the current classloader as pure as possible)
OSGi was selected to be used inside an EJB to handle some dynamic plugins.
While we don't expect Glassfish to facilitate this explicitly, we
would like it if the classloader remains as much as it is right now
for the EJB's to avoid upsetting this delicate environment.
Thank you for your time.
Regards,
--
Barry van Someren
---------------------------------------
Email: barry@bvansomeren.com
Email: goltharnl@gmail.com
Linkedin: http://www.linkedin.com/pub/1/b41/197
Www: http://blog.bvansomeren.com
On Oct 30, 2007 8:13 PM, John Clingan <John.Clingan@sun.com> wrote:
> If you have ideas of features or enhancements that you want in
> GlassFish V3, read on!
>
> GlassFish V1 was all about developer productivity and Java EE 5.
> GlassFish V2 adds enterprise features such as clustering and
> centralized administration. Now that GlassFish V2 has been released,
> it is time to begin planning for GlassFish V3. Before doing so, there
> needs to be a clear direction of where we are headed. We have outlined
> the high level themes for GlassFish V3 here (feel free to provide
> feedback on the themes):
> http://wiki.glassfish.java.net/Wiki.jsp?page=GlassFishV3Themes
>
> We would like to drill down a step further and begin to define
> GlassFish V3 with community involvement. That means you! Is there a
> feature or enhancement that you would like to see in GlassFish V3?
> Perhaps to make it easier to use or more relevant for your work
> environment?
> Please feel free to participate! I'd like to begin the discussion on
> this alias. Feel free to contact me directly as well at John dot
> Clingan at Sun dot COM. Depending on the level of interest, we can
> also set up a conference call and discuss in real time.
>
> Here are some sample questions that may stimulate some ideas:
>
> - A feature that would make software development significantly easier
> - A feature that differentiates GlassFish V3 from other application
> servers
> - A feature that is available with application server X, and would
> really benefit users if it were also in GlassFish V3
> - GlassFish would be easier to use if ...
> - If GlassFish had this feature I could deploy it to a broader
> production environment
>
> Thanks!
> John Clingan
> GlassFish / Sun Application Server Group Product Manger
>
> John dot Clingan at Sun dot COM
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 14, 2007 2:36 AM
in response to: Barry van Someren
|
|
|
Hi,
Maybe another smallish improvement that I forgot to list earlier.
When I redeploy an EAR using the upload option the "Filechoser"
rembembers the directory I was in when I last deployed.
When you use the feature to deploy a file already on the server it
seems to start from root.
Maybe a small improvement would be to by default make it point to the
directory the last EAR came from?
Regards,
--
Barry van Someren
---------------------------------------
Email: barry@bvansomeren.com
Email: goltharnl@gmail.com
Linkedin: http://www.linkedin.com/pub/1/b41/197
Www: http://blog.bvansomeren.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 14, 2007 2:34 PM
in response to: Barry van Someren
|
|
|
Barry van Someren wrote:
> Hi there,
>
> Hope I'm not too late to the party here, but some tidbits that I
> collected recently.. some of these have been mentioned here and I just
> want to second those.
>
> -Maven support (run embedded, have plugins for deployment)
> It would seem this already made the list
>
> -More fine grained control over (session) bean lifecycle, pooling and caching
> Correct me if I'm wrong, but it seems you can only control the total pool sizes.
> I'd like to be able to make a bigger pool of session beans that are
> known to be lighter and a smaller pool of certain utility and heavier
> beans to better tune how the system is loaded.
> We currently don't have any issues but it might be useful to allow fine tuning.
>
> -Keep improving error messages and error handling.
> Glassfish is going great in this department, keep at it as it helps me
> track down errors better.
>
> -Modules to replace Toplink by Hibernate
> Modules seem to be the new direction that Glassfish is taking and we
> would appreciate an easy to way to allow other implementations of JPA
> in.
I'm confused here (and I think you are the 2nd person who asks for it on this
thread). The JPA provider is pluggable according to the spec requirements since
V1. Is there anything more advanced that you are looking for?
thanks,
-marina
>
> -Allow the creation of Unit tests for EJB's by making an embedded
> Glassfish, much like embedded JBoss
> We unit test our EJB's using JBoss embedded (both to ensure our
> application stays honest and to have complete testing in our build)
> Currently we have to use JBoss embedded... having a Glassfish version
> is already listed in here and I can strongly second this
>
> -Keep working on the module/application installer, maybe integration
> within the admin interface would be nice.
> Glassfish comes with a small Java app to install extra's like portals etc.
> This is great and I hope to see this functionality inside the admin interface.
> Smack me if this is already implemented or listed please
>
> -While Glassfish will promote the use HK2, please make sure that those
> using OSGi within their applications will not be impacted too severely
> (IE try to keep the current classloader as pure as possible)
> OSGi was selected to be used inside an EJB to handle some dynamic plugins.
> While we don't expect Glassfish to facilitate this explicitly, we
> would like it if the classloader remains as much as it is right now
> for the EJB's to avoid upsetting this delicate environment.
>
> Thank you for your time.
>
> Regards,
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 14, 2007 9:49 PM
in response to: Barry van Someren
|
|
|
On Nov 14, 2007, at 1:30 AM, Barry van Someren wrote:
> Hi there,
>
> Hope I'm not too late to the party here, but some tidbits that I
> collected recently.. some of these have been mentioned here and I just
> want to second those.
>
Not too late!
> -Maven support (run embedded, have plugins for deployment)
> It would seem this already made the list
>
Yep, although I should say that we are doing our best to accommodate
as many requests as possible but don't guarantee that any particular
feature will make it in V3.
> -More fine grained control over (session) bean lifecycle, pooling
> and caching
> Correct me if I'm wrong, but it seems you can only control the total
> pool sizes.
> I'd like to be able to make a bigger pool of session beans that are
> known to be lighter and a smaller pool of certain utility and heavier
> beans to better tune how the system is loaded.
> We currently don't have any issues but it might be useful to allow
> fine tuning.
>
Good feedback.
> -Keep improving error messages and error handling.
> Glassfish is going great in this department, keep at it as it helps me
> track down errors better.
>
Thanks for the feedback.
> -Modules to replace Toplink by Hibernate
> Modules seem to be the new direction that Glassfish is taking and we
> would appreciate an easy to way to allow other implementations of JPA
> in.
>
As Marina mentioned in another response, this can already be done.
http://blogs.sun.com/theaquarium/entry/running_hibernate_in_glassfish
http://eskatos.wordpress.com/2007/10/09/hello-world/
> -Allow the creation of Unit tests for EJB's by making an embedded
> Glassfish, much like embedded JBoss
> We unit test our EJB's using JBoss embedded (both to ensure our
> application stays honest and to have complete testing in our build)
> Currently we have to use JBoss embedded... having a Glassfish version
> is already listed in here and I can strongly second this
>
Good feedback.
> -Keep working on the module/application installer, maybe integration
> within the admin interface would be nice.
> Glassfish comes with a small Java app to install extra's like
> portals etc.
> This is great and I hope to see this functionality inside the admin
> interface.
> Smack me if this is already implemented or listed please
>
Good feedback.
> -While Glassfish will promote the use HK2, please make sure that those
> using OSGi within their applications will not be impacted too severely
> (IE try to keep the current classloader as pure as possible)
> OSGi was selected to be used inside an EJB to handle some dynamic
> plugins.
> While we don't expect Glassfish to facilitate this explicitly, we
> would like it if the classloader remains as much as it is right now
> for the EJB's to avoid upsetting this delicate environment.
>
Thanks for *your* time! Great feedback.
> Thank you for your time.
>
> Regards,
>
> --
> Barry van Someren
> ---------------------------------------
> Email: barry@bvansomeren.com
> Email: goltharnl@gmail.com
> Linkedin: http://www.linkedin.com/pub/1/b41/197
> Www: http://blog.bvansomeren.com
>
>
> On Oct 30, 2007 8:13 PM, John Clingan <John.Clingan@sun.com> wrote:
>> If you have ideas of features or enhancements that you want in
>> GlassFish V3, read on!
>>
>> GlassFish V1 was all about developer productivity and Java EE 5.
>> GlassFish V2 adds enterprise features such as clustering and
>> centralized administration. Now that GlassFish V2 has been released,
>> it is time to begin planning for GlassFish V3. Before doing so, there
>> needs to be a clear direction of where we are headed. We have
>> outlined
>> the high level themes for GlassFish V3 here (feel free to provide
>> feedback on the themes):
>> http://wiki.glassfish.java.net/Wiki.jsp?page=GlassFishV3Themes
>>
>> We would like to drill down a step further and begin to define
>> GlassFish V3 with community involvement. That means you! Is there a
>> feature or enhancement that you would like to see in GlassFish V3?
>> Perhaps to make it easier to use or more relevant for your work
>> environment?
>> Please feel free to participate! I'd like to begin the discussion on
>> this alias. Feel free to contact me directly as well at John dot
>> Clingan at Sun dot COM. Depending on the level of interest, we can
>> also set up a conference call and discuss in real time.
>>
>> Here are some sample questions that may stimulate some ideas:
>>
>> - A feature that would make software development significantly easier
>> - A feature that differentiates GlassFish V3 from other application
>> servers
>> - A feature that is available with application server X, and would
>> really benefit users if it were also in GlassFish V3
>> - GlassFish would be easier to use if ...
>> - If GlassFish had this feature I could deploy it to a broader
>> production environment
>>
>> Thanks!
>> John Clingan
>> GlassFish / Sun Application Server Group Product Manger
>>
>> John dot Clingan at Sun dot COM
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
>> For additional commands, e-mail: users-help@glassfish.dev.java.net
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 15, 2007 4:23 AM
in response to: John Clingan
|
|
|
Marina, John,
Hi yes that will do of course.
I just meant that given Glassfish will become more modular, there
should maybe be separate modules so that you can pick which JPA will
be used.
Extra points if these modules can be added in the same way as the
extra's. (through the updatecenter or the admin interface)
I'd call this the least important thing I listed though and they would
certainly be a lot of work.
As for the Maven bits, I might be able to find some time to help in
this as I'm becoming ever more proficient with the joys and pleasures
of Maven.
I'll start by checking out the the current V3 work and seeing how the
maven builds are progressing.
Regards,
Barry
On Nov 15, 2007 6:49 AM, John Clingan <John.Clingan@sun.com> wrote:
>
> On Nov 14, 2007, at 1:30 AM, Barry van Someren wrote:
>
> > Hi there,
> >
> > Hope I'm not too late to the party here, but some tidbits that I
> > collected recently.. some of these have been mentioned here and I just
> > want to second those.
> >
>
> Not too late!
>
> > -Maven support (run embedded, have plugins for deployment)
> > It would seem this already made the list
> >
>
> Yep, although I should say that we are doing our best to accommodate
> as many requests as possible but don't guarantee that any particular
> feature will make it in V3.
>
> > -More fine grained control over (session) bean lifecycle, pooling
> > and caching
> > Correct me if I'm wrong, but it seems you can only control the total
> > pool sizes.
> > I'd like to be able to make a bigger pool of session beans that are
> > known to be lighter and a smaller pool of certain utility and heavier
> > beans to better tune how the system is loaded.
> > We currently don't have any issues but it might be useful to allow
> > fine tuning.
> >
>
> Good feedback.
>
> > -Keep improving error messages and error handling.
> > Glassfish is going great in this department, keep at it as it helps me
> > track down errors better.
> >
>
> Thanks for the feedback.
>
> > -Modules to replace Toplink by Hibernate
> > Modules seem to be the new direction that Glassfish is taking and we
> > would appreciate an easy to way to allow other implementations of JPA
> > in.
> >
>
> As Marina mentioned in another response, this can already be done.
> http://blogs.sun.com/theaquarium/entry/running_hibernate_in_glassfish
> http://eskatos.wordpress.com/2007/10/09/hello-world/
>
> > -Allow the creation of Unit tests for EJB's by making an embedded
> > Glassfish, much like embedded JBoss
> > We unit test our EJB's using JBoss embedded (both to ensure our
> > application stays honest and to have complete testing in our build)
> > Currently we have to use JBoss embedded... having a Glassfish version
> > is already listed in here and I can strongly second this
> >
>
> Good feedback.
>
> > -Keep working on the module/application installer, maybe integration
> > within the admin interface would be nice.
> > Glassfish comes with a small Java app to install extra's like
> > portals etc.
> > This is great and I hope to see this functionality inside the admin
> > interface.
> > Smack me if this is already implemented or listed please
> >
>
> Good feedback.
>
> > -While Glassfish will promote the use HK2, please make sure that those
> > using OSGi within their applications will not be impacted too severely
> > (IE try to keep the current classloader as pure as possible)
> > OSGi was selected to be used inside an EJB to handle some dynamic
> > plugins.
> > While we don't expect Glassfish to facilitate this explicitly, we
> > would like it if the classloader remains as much as it is right now
> > for the EJB's to avoid upsetting this delicate environment.
> >
>
> Thanks for *your* time! Great feedback.
>
>
> > Thank you for your time.
> >
> > Regards,
> >
> > --
> > Barry van Someren
> > ---------------------------------------
> > Email: barry@bvansomeren.com
> > Email: goltharnl@gmail.com
> > Linkedin: http://www.linkedin.com/pub/1/b41/197
> > Www: http://blog.bvansomeren.com
> >
> >
> > On Oct 30, 2007 8:13 PM, John Clingan <John.Clingan@sun.com> wrote:
> >> If you have ideas of features or enhancements that you want in
> >> GlassFish V3, read on!
> >>
> >> GlassFish V1 was all about developer productivity and Java EE 5.
> >> GlassFish V2 adds enterprise features such as clustering and
> >> centralized administration. Now that GlassFish V2 has been released,
> >> it is time to begin planning for GlassFish V3. Before doing so, there
> >> needs to be a clear direction of where we are headed. We have
> >> outlined
> >> the high level themes for GlassFish V3 here (feel free to provide
> >> feedback on the themes):
> >> http://wiki.glassfish.java.net/Wiki.jsp?page=GlassFishV3Themes
> >>
> >> We would like to drill down a step further and begin to define
> >> GlassFish V3 with community involvement. That means you! Is there a
> >> feature or enhancement that you would like to see in GlassFish V3?
> >> Perhaps to make it easier to use or more relevant for your work
> >> environment?
> >> Please feel free to participate! I'd like to begin the discussion on
> >> this alias. Feel free to contact me directly as well at John dot
> >> Clingan at Sun dot COM. Depending on the level of interest, we can
> >> also set up a conference call and discuss in real time.
> >>
> >> Here are some sample questions that may stimulate some ideas:
> >>
> >> - A feature that would make software development significantly easier
> >> - A feature that differentiates GlassFish V3 from other application
> >> servers
> >> - A feature that is available with application server X, and would
> >> really benefit users if it were also in GlassFish V3
> >> - GlassFish would be easier to use if ...
> >> - If GlassFish had this feature I could deploy it to a broader
> >> production environment
> >>
> >> Thanks!
> >> John Clingan
> >> GlassFish / Sun Application Server Group Product Manger
> >>
> >> John dot Clingan at Sun dot COM
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> >> For additional commands, e-mail: users-help@glassfish.dev.java.net
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> > For additional commands, e-mail: users-help@glassfish.dev.java.net
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
>
--
Barry van Someren
---------------------------------------
Email: barry@bvansomeren.com
Email: goltharnl@gmail.com
Linkedin: http://www.linkedin.com/pub/1/b41/197
Www: http://blog.bvansomeren.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 15, 2007 10:13 AM
in response to: Barry van Someren
|
|
|
This is good feedback. I did send out an email a few days back asking
what packages should be included in the update center.
http://forums.java.net/jive/thread.jspa?threadID=33157&tstart=45
Sounds like you are voting for Hibernate.
On Nov 15, 2007, at 4:23 AM, Barry van Someren wrote:
> Marina, John,
>
> Hi yes that will do of course.
> I just meant that given Glassfish will become more modular, there
> should maybe be separate modules so that you can pick which JPA will
> be used.
> Extra points if these modules can be added in the same way as the
> extra's. (through the updatecenter or the admin interface)
> I'd call this the least important thing I listed though and they would
> certainly be a lot of work.
>
> As for the Maven bits, I might be able to find some time to help in
> this as I'm becoming ever more proficient with the joys and pleasures
> of Maven.
> I'll start by checking out the the current V3 work and seeing how the
> maven builds are progressing.
>
> Regards,
>
> Barry
>
> On Nov 15, 2007 6:49 AM, John Clingan <John.Clingan@sun.com> wrote:
>>
>> On Nov 14, 2007, at 1:30 AM, Barry van Someren wrote:
>>
>>> Hi there,
>>>
>>> Hope I'm not too late to the party here, but some tidbits that I
>>> collected recently.. some of these have been mentioned here and I
>>> just
>>> want to second those.
>>>
>>
>> Not too late!
>>
>>> -Maven support (run embedded, have plugins for deployment)
>>> It would seem this already made the list
>>>
>>
>> Yep, although I should say that we are doing our best to accommodate
>> as many requests as possible but don't guarantee that any particular
>> feature will make it in V3.
>>
>>> -More fine grained control over (session) bean lifecycle, pooling
>>> and caching
>>> Correct me if I'm wrong, but it seems you can only control the total
>>> pool sizes.
>>> I'd like to be able to make a bigger pool of session beans that are
>>> known to be lighter and a smaller pool of certain utility and
>>> heavier
>>> beans to better tune how the system is loaded.
>>> We currently don't have any issues but it might be useful to allow
>>> fine tuning.
>>>
>>
>> Good feedback.
>>
>>> -Keep improving error messages and error handling.
>>> Glassfish is going great in this department, keep at it as it
>>> helps me
>>> track down errors better.
>>>
>>
>> Thanks for the feedback.
>>
>>> -Modules to replace Toplink by Hibernate
>>> Modules seem to be the new direction that Glassfish is taking and we
>>> would appreciate an easy to way to allow other implementations of
>>> JPA
>>> in.
>>>
>>
>> As Marina mentioned in another response, this can already be done.
>> http://blogs.sun.com/theaquarium/entry/running_hibernate_in_glassfish
>> http://eskatos.wordpress.com/2007/10/09/hello-world/
>>
>>> -Allow the creation of Unit tests for EJB's by making an embedded
>>> Glassfish, much like embedded JBoss
>>> We unit test our EJB's using JBoss embedded (both to ensure our
>>> application stays honest and to have complete testing in our build)
>>> Currently we have to use JBoss embedded... having a Glassfish
>>> version
>>> is already listed in here and I can strongly second this
>>>
>>
>> Good feedback.
>>
>>> -Keep working on the module/application installer, maybe integration
>>> within the admin interface would be nice.
>>> Glassfish comes with a small Java app to install extra's like
>>> portals etc.
>>> This is great and I hope to see this functionality inside the admin
>>> interface.
>>> Smack me if this is already implemented or listed please
>>>
>>
>> Good feedback.
>>
>>> -While Glassfish will promote the use HK2, please make sure that
>>> those
>>> using OSGi within their applications will not be impacted too
>>> severely
>>> (IE try to keep the current classloader as pure as possible)
>>> OSGi was selected to be used inside an EJB to handle some dynamic
>>> plugins.
>>> While we don't expect Glassfish to facilitate this explicitly, we
>>> would like it if the classloader remains as much as it is right now
>>> for the EJB's to avoid upsetting this delicate environment.
>>>
>>
>> Thanks for *your* time! Great feedback.
>>
>>
>>> Thank you for your time.
>>>
>>> Regards,
>>>
>>> --
>>> Barry van Someren
>>> ---------------------------------------
>>> Email: barry@bvansomeren.com
>>> Email: goltharnl@gmail.com
>>> Linkedin: http://www.linkedin.com/pub/1/b41/197
>>> Www: http://blog.bvansomeren.com
>>>
>>>
>>> On Oct 30, 2007 8:13 PM, John Clingan <John.Clingan@sun.com> wrote:
>>>> If you have ideas of features or enhancements that you want in
>>>> GlassFish V3, read on!
>>>>
>>>> GlassFish V1 was all about developer productivity and Java EE 5.
>>>> GlassFish V2 adds enterprise features such as clustering and
>>>> centralized administration. Now that GlassFish V2 has been
>>>> released,
>>>> it is time to begin planning for GlassFish V3. Before doing so,
>>>> there
>>>> needs to be a clear direction of where we are headed. We have
>>>> outlined
>>>> the high level themes for GlassFish V3 here (feel free to provide
>>>> feedback on the themes):
>>>> http://wiki.glassfish.java.net/Wiki.jsp?page=GlassFishV3Themes
>>>>
>>>> We would like to drill down a step further and begin to define
>>>> GlassFish V3 with community involvement. That means you! Is there a
>>>> feature or enhancement that you would like to see in GlassFish V3?
>>>> Perhaps to make it easier to use or more relevant for your work
>>>> environment?
>>>> Please feel free to participate! I'd like to begin the
>>>> discussion on
>>>> this alias. Feel free to contact me directly as well at John dot
>>>> Clingan at Sun dot COM. Depending on the level of interest, we can
>>>> also set up a conference call and discuss in real time.
>>>>
>>>> Here are some sample questions that may stimulate some ideas:
>>>>
>>>> - A feature that would make software development significantly
>>>> easier
>>>> - A feature that differentiates GlassFish V3 from other application
>>>> servers
>>>> - A feature that is available with application server X, and would
>>>> really benefit users if it were also in GlassFish V3
>>>> - GlassFish would be easier to use if ...
>>>> - If GlassFish had this feature I could deploy it to a broader
>>>> production environment
>>>>
>>>> Thanks!
>>>> John Clingan
>>>> GlassFish / Sun Application Server Group Product Manger
>>>>
>>>> John dot Clingan at Sun dot COM
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
>>>> For additional commands, e-mail: users-help@glassfish.dev.java.net
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
>>> For additional commands, e-mail: users-help@glassfish.dev.java.net
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
>> For additional commands, e-mail: users-help@glassfish.dev.java.net
>>
>>
>
>
>
> --
> Barry van Someren
> ---------------------------------------
> Email: barry@bvansomeren.com
> Email: goltharnl@gmail.com
> Linkedin: http://www.linkedin.com/pub/1/b41/197
> Www: http://blog.bvansomeren.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 16, 2007 5:48 AM
in response to: John Clingan
|
|
|
Jesper,
I have responded to your query via Alexis. Maybe there is a way to do this already?
Regards,
Kedar
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 16, 2007 7:05 AM
in response to: km
|
|
|
I did not see any suggestions as to how this could be done for external libraries for which you don't have the source code or might even not know the name of the MBeans registered.
But yes do this manually as I wrote is possble but I feel that the application sandbox is less than perfekt.
The suggested design that I suggested is quite elegant and easy to implement in my mind. Though it requires an AOP framework as was one of my other requests as well.
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 16, 2007 8:05 AM
in response to: jesper_soderlund
|
|
|
I agree that AOP might be something to look into, but I don't think you should be
integrating third-party libraries that register arbitrary MBeans.
In the future, we do want a better integration of JMX into Java EE.
- Kedar
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 17, 2007 4:14 PM
in response to: John Clingan
|
|
|
Well, personally I don't mind too much but some of my colleagues seem to do.
It will be interesting to see what items make it to the updatecenter.
Components for Glassfish (things like JPA implementations, JMS queue's
etc) do seem like a nice fit.
On Nov 15, 2007 7:13 PM, John Clingan <John.Clingan@sun.com> wrote:
> This is good feedback. I did send out an email a few days back asking
> what packages should be included in the update center.
> http://forums.java.net/jive/thread.jspa?threadID=33157&tstart=45
>
> Sounds like you are voting for Hibernate.
>
>
> On Nov 15, 2007, at 4:23 AM, Barry van Someren wrote:
>
> > Marina, John,
> >
> > Hi yes that will do of course.
> > I just meant that given Glassfish will become more modular, there
> > should maybe be separate modules so that you can pick which JPA will
> > be used.
> > Extra points if these modules can be added in the same way as the
> > extra's. (through the updatecenter or the admin interface)
> > I'd call this the least important thing I listed though and they would
> > certainly be a lot of work.
> >
> > As for the Maven bits, I might be able to find some time to help in
> > this as I'm becoming ever more proficient with the joys and pleasures
> > of Maven.
> > I'll start by checking out the the current V3 work and seeing how the
> > maven builds are progressing.
> >
> > Regards,
> >
> > Barry
> >
> > On Nov 15, 2007 6:49 AM, John Clingan <John.Clingan@sun.com> wrote:
> >>
> >> On Nov 14, 2007, at 1:30 AM, Barry van Someren wrote:
> >>
> >>> Hi there,
> >>>
> >>> Hope I'm not too late to the party here, but some tidbits that I
> >>> collected recently.. some of these have been mentioned here and I
> >>> just
> >>> want to second those.
> >>>
> >>
> >> Not too late!
> >>
> >>> -Maven support (run embedded, have plugins for deployment)
> >>> It would seem this already made the list
> >>>
> >>
> >> Yep, although I should say that we are doing our best to accommodate
> >> as many requests as possible but don't guarantee that any particular
> >> feature will make it in V3.
> >>
> >>> -More fine grained control over (session) bean lifecycle, pooling
> >>> and caching
> >>> Correct me if I'm wrong, but it seems you can only control the total
> >>> pool sizes.
> >>> I'd like to be able to make a bigger pool of session beans that are
> >>> known to be lighter and a smaller pool of certain utility and
> >>> heavier
> >>> beans to better tune how the system is loaded.
> >>> We currently don't have any issues but it might be useful to allow
> >>> fine tuning.
> >>>
> >>
> >> Good feedback.
> >>
> >>> -Keep improving error messages and error handling.
> >>> Glassfish is going great in this department, keep at it as it
> >>> helps me
> >>> track down errors better.
> >>>
> >>
> >> Thanks for the feedback.
> >>
> >>> -Modules to replace Toplink by Hibernate
> >>> Modules seem to be the new direction that Glassfish is taking and we
> >>> would appreciate an easy to way to allow other implementations of
> >>> JPA
> >>> in.
> >>>
> >>
> >> As Marina mentioned in another response, this can already be done.
> >> http://blogs.sun.com/theaquarium/entry/running_hibernate_in_glassfish
> >> http://eskatos.wordpress.com/2007/10/09/hello-world/
> >>
> >>> -Allow the creation of Unit tests for EJB's by making an embedded
> >>> Glassfish, much like embedded JBoss
> >>> We unit test our EJB's using JBoss embedded (both to ensure our
> >>> application stays honest and to have complete testing in our build)
> >>> Currently we have to use JBoss embedded... having a Glassfish
> >>> version
> >>> is already listed in here and I can strongly second this
> >>>
> >>
> >> Good feedback.
> >>
> >>> -Keep working on the module/application installer, maybe integration
> >>> within the admin interface would be nice.
> >>> Glassfish comes with a small Java app to install extra's like
> >>> portals etc.
> >>> This is great and I hope to see this functionality inside the admin
> >>> interface.
> >>> Smack me if this is already implemented or listed please
> >>>
> >>
> >> Good feedback.
> >>
> >>> -While Glassfish will promote the use HK2, please make sure that
> >>> those
> >>> using OSGi within their applications will not be impacted too
> >>> severely
> >>> (IE try to keep the current classloader as pure as possible)
> >>> OSGi was selected to be used inside an EJB to handle some dynamic
> >>> plugins.
> >>> While we don't expect Glassfish to facilitate this explicitly, we
> >>> would like it if the classloader remains as much as it is right now
> >>> for the EJB's to avoid upsetting this delicate environment.
> >>>
> >>
> >> Thanks for *your* time! Great feedback.
> >>
> >>
> >>> Thank you for your time.
> >>>
> >>> Regards,
> >>>
> >>> --
> >>> Barry van Someren
> >>> ---------------------------------------
> >>> Email: barry@bvansomeren.com
> >>> Email: goltharnl@gmail.com
> >>> Linkedin: http://www.linkedin.com/pub/1/b41/197
> >>> Www: http://blog.bvansomeren.com
> >>>
> >>>
> >>> On Oct 30, 2007 8:13 PM, John Clingan <John.Clingan@sun.com> wrote:
> >>>> If you have ideas of features or enhancements that you want in
> >>>> GlassFish V3, read on!
> >>>>
> >>>> GlassFish V1 was all about developer productivity and Java EE 5.
> >>>> GlassFish V2 adds enterprise features such as clustering and
> >>>> centralized administration. Now that GlassFish V2 has been
> >>>> released,
> >>>> it is time to begin planning for GlassFish V3. Before doing so,
> >>>> there
> >>>> needs to be a clear direction of where we are headed. We have
> >>>> outlined
> >>>> the high level themes for GlassFish V3 here (feel free to provide
> >>>> feedback on the themes):
> >>>> http://wiki.glassfish.java.net/Wiki.jsp?page=GlassFishV3Themes
> >>>>
> >>>> We would like to drill down a step further and begin to define
> >>>> GlassFish V3 with community involvement. That means you! Is there a
> >>>> feature or enhancement that you would like to see in GlassFish V3?
> >>>> Perhaps to make it easier to use or more relevant for your work
> >>>> environment?
> >>>> Please feel free to participate! I'd like to begin the
> >>>> discussion on
> >>>> this alias. Feel free to contact me directly as well at John dot
> >>>> Clingan at Sun dot COM. Depending on the level of interest, we can
> >>>> also set up a conference call and discuss in real time.
> >>>>
> >>>> Here are some sample questions that may stimulate some ideas:
> >>>>
> >>>> - A feature that would make software development significantly
> >>>> easier
> >>>> - A feature that differentiates GlassFish V3 from other application
> >>>> servers
> >>>> - A feature that is available with application server X, and would
> >>>> really benefit users if it were also in GlassFish V3
> >>>> - GlassFish would be easier to use if ...
> >>>> - If GlassFish had this feature I could deploy it to a broader
> >>>> production environment
> >>>>
> >>>> Thanks!
> >>>> John Clingan
> >>>> GlassFish / Sun Application Server Group Product Manger
> >>>>
> >>>> John dot Clingan at Sun dot COM
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> >>>> For additional commands, e-mail: users-help@glassfish.dev.java.net
> >>>>
> >>>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> >>> For additional commands, e-mail: users-help@glassfish.dev.java.net
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> >> For additional commands, e-mail: users-help@glassfish.dev.java.net
> >>
> >>
> >
> >
> >
> > --
> > Barry van Someren
> > ---------------------------------------
> > Email: barry@bvansomeren.com
> > Email: goltharnl@gmail.com
> > Linkedin: http://www.linkedin.com/pub/1/b41/197
> > Www: http://blog.bvansomeren.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> > For additional commands, e-mail: users-help@glassfish.dev.java.net
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
>
--
Barry van Someren
---------------------------------------
Email: barry@bvansomeren.com
Email: goltharnl@gmail.com
Linkedin: http://www.linkedin.com/pub/1/b41/197
Www: http://blog.bvansomeren.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 16, 2007 5:42 AM
in response to: John Clingan
|
|
|
I ran into an issue that I want to put up on the board for consideration to fixing in future versions, this is in the border-land between bug and feature so I'd much like this improvement in 2.1
* Improved hot deployment functionality with regards to registered MBeans
We are experiencing problems in hot deploying applications which have registered their own custom MBeans. Where we are in control of our own MBeans this might not be a bit problem since we can then do an unregister and then a register again. The problematic situation is where we have thirdparty libraries which register the MBeans and we have no control of the source code.
A possible design in glassfish to solve this situation is to make use of an AOP framework to intercept the calls to “registerMBean / createMBean� and setup some context information which mbeans an application has registered and when undeploying it also unregister the MBeans that this app has registered. It’s a quite nice and elegant solution in my mind.
Here is some sample code to demonstrate the problem. Make a war with this and access the servlet once, then redeploy and access it again, it will fail. This is perhaps not a major issue if the code is your own, then just write a manual unregister/register. But the big problem is with thirdparty libraries which are less than optimally written. In all I think GF has a small blame in this and that the application sandbox is not perfect eventough this is in the land outside of the specifications.
/**
* Very Simple test servlet to test compression filter
* @author Amy Roh
* @version $Revision: 1.3 $, $Date: 2006/10/12 14:31:29 $
*/
public class CompressionFilterTestServlet extends HttpServlet {
private static interface DummyMBean
{
public String getName();
public void setName(String val);
}
private static class Dummy implements DummyMBean
{
private String name = "Kalle";
public String getName() { return name; }
public void setName(String val) { name = val; }
}
Dummy mbean;
public CompressionFilterTestServlet()
{
System.out.println("HejsanHoppsan!");
try {
MBeanServer srv = ManagementFactory.getPlatformMBeanServer();
mbean = new Dummy();
ObjectName name = ObjectName.getInstance("netent:type=dummy,name=kalle");
srv.registerMBean(mbean, name);
} catch (InstanceAlreadyExistsException ex) {
Logger.getLogger(CompressionFilterTestServlet.class.getName()).log(Level.SEVERE, "Not good, instance already exists", ex);
} catch (Exception ex) {
Logger.getLogger(CompressionFilterTestServlet.class.getName()).log(Level.SEVERE, "Not good", ex);
}
}
public void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
ServletOutputStream out = response.getOutputStream();
response.setContentType("text/plain");
Enumeration e = ((HttpServletRequest)request).getHeaders("Accept-Encoding");
while (e.hasMoreElements()) {
String name = (String)e.nextElement();
out.println(name);
if (name.indexOf("gzip") != -1) {
out.println("gzip supported -- able to compress");
}
else {
out.println("gzip not supported");
}
}
out.println("Compression Filter Test Servlet");
out.close();
}
}
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
Posted:
Nov 16, 2007 11:25 AM
in response to: John Clingan
|
|
|
A new one...
The ability within the console to "clone" a resource, such as a connection pool, etc. We run in to this all the time, and it would be a nice benny to be able to clone a pool and simply change the database or whatever minor tweak is necessary vs tabbing back and forth across windows copying values.
|
|
|
|
|
|
|
|
|
Re: GlassFish V3 planning - What do *you* want in GlassFish V3?
| | | |
