6:46 a.m.
One of the very useful features in previous JBoss AS versions was the
ability of the server to identify and pick up changes to a .jsp page in
an exploded deployment and serve the updated content on next request.
Trying this out in JBoss AS 7.0.0.Beta3, I see that this no longer works:
1) Create and deploy a test.war (along with a test.war.dodeploy) in the
standalone/deployments.
2) test.war contains a test.jsp with an intentional syntax error in it
3) Access the jsp via browser and see the (expected) compilation error.
Now open the test.jsp file in a text editor, from the exploded test.war
deployment, and edit it to fix the error
4) Access the jsp via browser again. Tried it more than once. I still
see the compilation failure i.e. the jsp changes aren't being picked up
anymore. I had to undeploy and redeploy the exploded deployment for the
changes to be picked up.
I remember that in previous versions of AS there were some parameters
for the jsp compiler/executor which by default enabled this check for
jsp changes. Has this changed in AS7? Where and what values are set
currently? Or has this got something to do with the way we handle
exploded deployment in AS7?
-Jaikiran
7:31 a.m.
On Thu, 2011-04-21 at 17:16 +0530, Jaikiran Pai wrote:
One of the very useful features in previous JBoss AS versions was
the
ability of the server to identify and pick up changes to a .jsp page
in an exploded deployment and serve the updated content on next
request. Trying this out in JBoss AS 7.0.0.Beta3, I see that this no
longer works:
1) Create and deploy a test.war (along with a test.war.dodeploy) in
the standalone/deployments.
2) test.war contains a test.jsp with an intentional syntax error in it
3) Access the jsp via browser and see the (expected) compilation
error. Now open the test.jsp file in a text editor, from the exploded
test.war deployment, and edit it to fix the error
4) Access the jsp via browser again. Tried it more than once. I still
see the compilation failure i.e. the jsp changes aren't being picked
up anymore. I had to undeploy and redeploy the exploded deployment for
the changes to be picked up.
I remember that in previous versions of AS there were some parameters
for the jsp compiler/executor which by default enabled this check for
jsp changes. Has this changed in AS7? Where and what values are set
currently? Or has this got something to do with the way we handle
exploded deployment in AS7?
Well, you have to enable either development mode, or the background
check for recompilation :)
http://pastebin.com/LY1Ca4HV
--
Remy Maucherat <rmaucher(a)redhat.com>
Red Hat Inc
9:07 a.m.
That worked, thanks!
Any chance we can enable this by default for the standalone server?
-Jaikiran
On Thursday 21 April 2011 06:01 PM, Remy Maucherat wrote:
On Thu, 2011-04-21 at 17:16 +0530, Jaikiran Pai wrote:
> One of the very useful features in previous JBoss AS versions was the
> ability of the server to identify and pick up changes to a .jsp page
> in an exploded deployment and serve the updated content on next
> request. Trying this out in JBoss AS 7.0.0.Beta3, I see that this no
> longer works:
>
> 1) Create and deploy a test.war (along with a test.war.dodeploy) in
> the standalone/deployments.
> 2) test.war contains a test.jsp with an intentional syntax error in it
> 3) Access the jsp via browser and see the (expected) compilation
> error. Now open the test.jsp file in a text editor, from the exploded
> test.war deployment, and edit it to fix the error
> 4) Access the jsp via browser again. Tried it more than once. I still
> see the compilation failure i.e. the jsp changes aren't being picked
> up anymore. I had to undeploy and redeploy the exploded deployment for
> the changes to be picked up.
>
> I remember that in previous versions of AS there were some parameters
> for the jsp compiler/executor which by default enabled this check for
> jsp changes. Has this changed in AS7? Where and what values are set
> currently? Or has this got something to do with the way we handle
> exploded deployment in AS7?
Well, you have to enable either development mode, or the background
check for recompilation :)
http://pastebin.com/LY1Ca4HV
5:50 p.m.
I second this being a default, I would also ask that some discussion be created around
user experience and what/how we target the different needs of the different communities of
users we have.
Jim Tyrrell
Senior JBoss Solutions Architect
Did you see RHT on CNBC's Mad Money?
http://www.cnbc.com/id/39401056
On Apr 21, 2011, at 8:07 AM, Jaikiran Pai wrote:
That worked, thanks!
Any chance we can enable this by default for the standalone server?
-Jaikiran
On Thursday 21 April 2011 06:01 PM, Remy Maucherat wrote:
> On Thu, 2011-04-21 at 17:16 +0530, Jaikiran Pai wrote:
>> One of the very useful features in previous JBoss AS versions was the
>> ability of the server to identify and pick up changes to a .jsp page
>> in an exploded deployment and serve the updated content on next
>> request. Trying this out in JBoss AS 7.0.0.Beta3, I see that this no
>> longer works:
>>
>> 1) Create and deploy a test.war (along with a test.war.dodeploy) in
>> the standalone/deployments.
>> 2) test.war contains a test.jsp with an intentional syntax error in it
>> 3) Access the jsp via browser and see the (expected) compilation
>> error. Now open the test.jsp file in a text editor, from the exploded
>> test.war deployment, and edit it to fix the error
>> 4) Access the jsp via browser again. Tried it more than once. I still
>> see the compilation failure i.e. the jsp changes aren't being picked
>> up anymore. I had to undeploy and redeploy the exploded deployment for
>> the changes to be picked up.
>>
>> I remember that in previous versions of AS there were some parameters
>> for the jsp compiler/executor which by default enabled this check for
>> jsp changes. Has this changed in AS7? Where and what values are set
>> currently? Or has this got something to do with the way we handle
>> exploded deployment in AS7?
>
> Well, you have to enable either development mode, or the background
> check for recompilation :)
>
> http://pastebin.com/LY1Ca4HV
>
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
5:35 a.m.
a +1000's...since finding all those development flags is going to be impossible
if that trend continues of having subsystem specific flags for this.
/max
On Apr 21, 2011, at 16:07, Jaikiran Pai wrote:
That worked, thanks!
Any chance we can enable this by default for the standalone server?
-Jaikiran
On Thursday 21 April 2011 06:01 PM, Remy Maucherat wrote:
> On Thu, 2011-04-21 at 17:16 +0530, Jaikiran Pai wrote:
>> One of the very useful features in previous JBoss AS versions was the
>> ability of the server to identify and pick up changes to a .jsp page
>> in an exploded deployment and serve the updated content on next
>> request. Trying this out in JBoss AS 7.0.0.Beta3, I see that this no
>> longer works:
>>
>> 1) Create and deploy a test.war (along with a test.war.dodeploy) in
>> the standalone/deployments.
>> 2) test.war contains a test.jsp with an intentional syntax error in it
>> 3) Access the jsp via browser and see the (expected) compilation
>> error. Now open the test.jsp file in a text editor, from the exploded
>> test.war deployment, and edit it to fix the error
>> 4) Access the jsp via browser again. Tried it more than once. I still
>> see the compilation failure i.e. the jsp changes aren't being picked
>> up anymore. I had to undeploy and redeploy the exploded deployment for
>> the changes to be picked up.
>>
>> I remember that in previous versions of AS there were some parameters
>> for the jsp compiler/executor which by default enabled this check for
>> jsp changes. Has this changed in AS7? Where and what values are set
>> currently? Or has this got something to do with the way we handle
>> exploded deployment in AS7?
>
> Well, you have to enable either development mode, or the background
> check for recompilation :)
>
> http://pastebin.com/LY1Ca4HV
>
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
/max
http://about.me/maxandersen
6:05 a.m.
On Tue, 2011-04-26 at 12:35 +0200, Max Rydahl Andersen wrote:
a +1000's...since finding all those development flags is going to
be impossible
if that trend continues of having subsystem specific flags for this.
The better default will now be used: development will remain as "false".
Development is very expensive performance wise, and is not TCK
compliant.
The domain is a centralized config, fully documented, dynamic, so it
should more practical to use than the previous files. I understand
there's an initial learning period, but it should be worth it.
--
Remy Maucherat <rmaucher(a)redhat.com>
Red Hat Inc
6:10 a.m.
On Tuesday 26 April 2011 04:35 PM, Remy Maucherat wrote:
On Tue, 2011-04-26 at 12:35 +0200, Max Rydahl Andersen wrote:
> a +1000's...since finding all those development flags is going to be impossible
> if that trend continues of having subsystem specific flags for this.
The better default will now be used: development will remain as "false".
IMO, before going to production with the server, any developer/team
would go through a development phase in which he would definitely like
this feature. So having this turned on by default (atleast in standalone
mode), IMO, makes sense.
P.S: I created https://issues.jboss.org/browse/AS7-659 and was about to
send out a pull request with a patch, before I saw this reply. If
there's any objection to this change, then I'll wait for a resolution on
this discussion.
-Jaikiran
Development is very expensive performance wise, and is not TCK
compliant.
The domain is a centralized config, fully documented, dynamic, so it
should more practical to use than the previous files. I understand
there's an initial learning period, but it should be worth it.
6:22 a.m.
On Tue, 2011-04-26 at 16:40 +0530, Jaikiran Pai wrote:
> The better default will now be used: development will remain as
"false".
IMO, before going to production with the server, any developer/team
would go through a development phase in which he would definitely like
this feature. So having this turned on by default (atleast in standalone
mode), IMO, makes sense.
P.S: I created https://issues.jboss.org/browse/AS7-659 and was about to
send out a pull request with a patch, before I saw this reply. If
there's any objection to this change, then I'll wait for a resolution on
this discussion.
I have rejected the jira.
--
Remy Maucherat <rmaucher(a)redhat.com>
Red Hat Inc
6:25 a.m.
Thinking a bit more about this, I don't see any use of supporting
exploded deployments (out of the box) if we don't support dynamic
changes to .jsps (out of the box). What else can be changed dynamically
in an exploded deployment?
-Jaikiran
On Tuesday 26 April 2011 04:52 PM, Remy Maucherat wrote:
On Tue, 2011-04-26 at 16:40 +0530, Jaikiran Pai wrote:
>> The better default will now be used: development will remain as
"false".
> IMO, before going to production with the server, any developer/team
> would go through a development phase in which he would definitely like
> this feature. So having this turned on by default (atleast in standalone
> mode), IMO, makes sense.
>
> P.S: I created https://issues.jboss.org/browse/AS7-659 and was about to
> send out a pull request with a patch, before I saw this reply. If
> there's any objection to this change, then I'll wait for a resolution on
> this discussion.
I have rejected the jira.
6:46 a.m.
On Tue, 2011-04-26 at 16:55 +0530, Jaikiran Pai wrote:
Thinking a bit more about this, I don't see any use of supporting
exploded deployments (out of the box) if we don't support dynamic
changes to .jsps (out of the box). What else can be changed dynamically
in an exploded deployment?
Well, everything can be easily updated, like static files, and there are
plenty of dynamic pages tech out there. JSP is actually not dynamic
because it uses compilation, although this is hidden, they are actually
servlets with a small runtime.
There are plenty of possibilities for you:
- Make your updates in place, then add a .dodeploy. That's more robust
(it allows classes changes), and still far faster to use an exploded
deployment.
- Add the development mode in the JSP config if you're working with
exploded deployments, and anticipate only JSP updates. Sorry, but this
is a rather specific situation right now, it's no longer 2001.
--
Remy Maucherat <rmaucher(a)redhat.com>
Red Hat Inc
6:58 a.m.
Well, everything can be easily updated, like static files, and there are
plenty of dynamic pages tech out there. JSP is actually not dynamic
because it uses compilation, although this is hidden, they are actually
servlets with a small runtime.
There are plenty of possibilities for you:
- Make your updates in place, then add a .dodeploy. That's more robust
(it allows classes changes), and still far faster to use an exploded
deployment.
How is that faster for anything but small examples ? it will invalidate running sessions
and require
bigger items (such as Hibernate/JPA, Spring configuration etc. to have to restart too.)
- Add the development mode in the JSP config if you're working
with
exploded deployments, and anticipate only JSP updates. Sorry, but this
is a rather specific situation right now, it's no longer 2001.
If this is just for JSP compilation it is less of an issue.
Is JSF facelets refresh also disabled by default or will it be ?
/max
http://about.me/maxandersen
9:02 a.m.
New subject: Changes to .jsp in an exploded deployment no longer picked up?
The default for JSF is production mode. JSF actually has four modes,
"Development", "UnitTest", "SystemTest", and
"Production". But
"Development" and "Production" are the only ones used by the JSF impl.
Usually, the developer would set this as a context param in web.xml.
It can also be set via JNDI.
As I was pointing out earlier, Development mode for JSF Facelets xhtml
files acts like JSP. We need to support exploded deployment to make
it worthwhile.
Stan
Quoting Max Rydahl Andersen <max.andersen(a)redhat.com>:
>
> Well, everything can be easily updated, like static files, and there are
> plenty of dynamic pages tech out there. JSP is actually not dynamic
> because it uses compilation, although this is hidden, they are actually
> servlets with a small runtime.
>
> There are plenty of possibilities for you:
> - Make your updates in place, then add a .dodeploy. That's more robust
> (it allows classes changes), and still far faster to use an exploded
> deployment.
How is that faster for anything but small examples ? it will
invalidate running sessions and require
bigger items (such as Hibernate/JPA, Spring configuration etc. to
have to restart too.)
> - Add the development mode in the JSP config if you're working with
> exploded deployments, and anticipate only JSP updates. Sorry, but this
> is a rather specific situation right now, it's no longer 2001.
If this is just for JSP compilation it is less of an issue.
Is JSF facelets refresh also disabled by default or will it be ?
/max
http://about.me/maxandersen
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
8:39 a.m.
New subject: Changes to .jsp in an exploded deployment no longer picked up?
Quoting Jaikiran Pai <jpai(a)redhat.com>:
Thinking a bit more about this, I don't see any use of
supporting
exploded deployments (out of the box) if we don't support dynamic
changes to .jsps (out of the box). What else can be changed dynamically
in an exploded deployment?
xhtml (Facelets) pages can behave the same as JSP's as long as you are
in development mode.
-Jaikiran
On Tuesday 26 April 2011 04:52 PM, Remy Maucherat wrote:
> On Tue, 2011-04-26 at 16:40 +0530, Jaikiran Pai wrote:
>>> The better default will now be used: development will remain as
"false".
>> IMO, before going to production with the server, any developer/team
>> would go through a development phase in which he would definitely like
>> this feature. So having this turned on by default (atleast in standalone
>> mode), IMO, makes sense.
>>
>> P.S: I created https://issues.jboss.org/browse/AS7-659 and was about to
>> send out a pull request with a patch, before I saw this reply. If
>> there's any objection to this change, then I'll wait for a resolution on
>> this discussion.
>
> I have rejected the jira.
>
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
8:56 a.m.
New subject: Changes to .jsp in an exploded deployment no longer picked up?
My two cents,
As we do today, I am thinking you need to have configs out of the box that can be
started.
Production
Development
Maybe even JMS
or WS
or....
I think prepackaged tested configs are a good idea as one size will not fit all. We have
done this for a long time and am wondering out loud why that notion would be removed?
Jim Tyrrell
Senior JBoss Solutions Architect
Did you see RHT on CNBC's Mad Money?
http://www.cnbc.com/id/39401056
On Apr 26, 2011, at 7:39 AM, ssilvert(a)redhat.com wrote:
Quoting Jaikiran Pai <jpai(a)redhat.com>:
> Thinking a bit more about this, I don't see any use of supporting
> exploded deployments (out of the box) if we don't support dynamic
> changes to .jsps (out of the box). What else can be changed dynamically
> in an exploded deployment?
xhtml (Facelets) pages can behave the same as JSP's as long as you are
in development mode.
>
> -Jaikiran
> On Tuesday 26 April 2011 04:52 PM, Remy Maucherat wrote:
>> On Tue, 2011-04-26 at 16:40 +0530, Jaikiran Pai wrote:
>>>> The better default will now be used: development will remain as
"false".
>>> IMO, before going to production with the server, any developer/team
>>> would go through a development phase in which he would definitely like
>>> this feature. So having this turned on by default (atleast in standalone
>>> mode), IMO, makes sense.
>>>
>>> P.S: I created https://issues.jboss.org/browse/AS7-659 and was about to
>>> send out a pull request with a patch, before I saw this reply. If
>>> there's any objection to this change, then I'll wait for a resolution
on
>>> this discussion.
>>
>> I have rejected the jira.
>>
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
9:46 a.m.
New subject: Changes to .jsp in an exploded deployment no longer picked up?
From: "Jim Tyrrell" <jtyrrell(a)redhat.com>
To: "jboss-as7-dev(a)lists.jboss.org Development"
<jboss-as7-dev(a)lists.jboss.org>
Sent: Tuesday, April 26, 2011 7:56:11 AM
Subject: Re: [jboss-as7-dev] Changes to .jsp in an exploded deployment no longer picked
up?
My two cents,
As we do today, I am thinking you need to have configs out of the box that can be started.
Production
Development
Maybe even JMS
or WS
or....
I think prepackaged tested configs are a good idea as one size will not fit all. We have
done this for a long time and am wondering out loud why that notion would be removed?
There is a requirement in the PRD to have a development configuration and a production
configuration, but that is specific to EAP. Traditionally, we have made the AS
distribution more "development" focused out-of-the-box.
I'm not sure, in this specific case what is the best option, but EAP will have a
production and development configuration (perhaps a script that sets things up for either
using the management API).
Andy
Jim Tyrrell
Senior JBoss Solutions Architect
Did you see RHT on CNBC's Mad Money?
http://www.cnbc.com/id/39401056
On Apr 26, 2011, at 7:39 AM, ssilvert(a)redhat.com wrote:
Quoting Jaikiran Pai < jpai(a)redhat.com >:
Thinking a bit more about this, I don't see any use of supporting
exploded deployments (out of the box) if we don't support dynamic
changes to .jsps (out of the box). What else can be changed dynamically
in an exploded deployment?
xhtml (Facelets) pages can behave the same as JSP's as long as you are
in development mode.
-Jaikiran
On Tuesday 26 April 2011 04:52 PM, Remy Maucherat wrote:
On Tue, 2011-04-26 at 16:40 +0530, Jaikiran Pai wrote:
The better default will now be used: development will remain as "false".
IMO, before going to production with the server, any developer/team
would go through a development phase in which he would definitely like
this feature. So having this turned on by default (atleast in standalone
mode), IMO, makes sense.
P.S: I created https://issues.jboss.org/browse/AS7-659 and was about to
send out a pull request with a patch, before I saw this reply. If
there's any objection to this change, then I'll wait for a resolution on
this discussion.
I have rejected the jira.
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
9:53 a.m.
New subject: Changes to .jsp in an exploded deployment no longer picked up?
Andy,
So if AS 7 is more development focused, I agree it can/should be, can any and all
decisions made/discussed/etc on this list, make that experience the best it can be.
Worrisome threads in the last week:
Should a welcome page exist
Should it be enabled to have a .jsp to be hot deployed
How should lifecyles of datasource deployments be
"configured/monitored/changed"
On a side vein I still worry about adoption and the learning curve of all of this new
amazing stuff.
Probably a few others, but those have been on my mind this week.
Jim Tyrrell
Senior JBoss Solutions Architect
Did you see RHT on CNBC's Mad Money?
http://www.cnbc.com/id/39401056
On Apr 26, 2011, at 8:46 AM, Andrig Miller wrote:
From: "Jim Tyrrell" <jtyrrell(a)redhat.com>
To: "jboss-as7-dev(a)lists.jboss.org Development"
<jboss-as7-dev(a)lists.jboss.org>
Sent: Tuesday, April 26, 2011 7:56:11 AM
Subject: Re: [jboss-as7-dev] Changes to .jsp in an exploded deployment no
longer picked up?
My two cents,
As we do today, I am thinking you need to have configs out of the box that can be
started.
Production
Development
Maybe even JMS
or WS
or....
I think prepackaged tested configs are a good idea as one size will not fit all. We have
done this for a long time and am wondering out loud why that notion would be removed?
There is a requirement in the PRD to have a development configuration and a production
configuration, but that is specific to EAP. Traditionally, we have made the AS
distribution more "development" focused out-of-the-box.
I'm not sure, in this specific case what is the best option, but EAP will have a
production and development configuration (perhaps a script that sets things up for either
using the management API).
Andy
Jim Tyrrell
Senior JBoss Solutions Architect
Did you see RHT on CNBC's Mad Money?
http://www.cnbc.com/id/39401056
On Apr 26, 2011, at 7:39 AM, ssilvert(a)redhat.com wrote:
Quoting Jaikiran Pai <jpai(a)redhat.com>:
Thinking a bit more about this, I don't see any use of supporting
exploded deployments (out of the box) if we don't support dynamic
changes to .jsps (out of the box). What else can be changed dynamically
in an exploded deployment?
xhtml (Facelets) pages can behave the same as JSP's as long as you are
in development mode.
-Jaikiran
On Tuesday 26 April 2011 04:52 PM, Remy Maucherat wrote:
On Tue, 2011-04-26 at 16:40 +0530, Jaikiran Pai wrote:
The better default will now be used: development will remain as "false".
IMO, before going to production with the server, any developer/team
would go through a development phase in which he would definitely like
this feature. So having this turned on by default (atleast in standalone
mode), IMO, makes sense.
P.S: I created https://issues.jboss.org/browse/AS7-659 and was about to
send out a pull request with a patch, before I saw this reply. If
there's any objection to this change, then I'll wait for a resolution on
this discussion.
I have rejected the jira.
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
9:56 a.m.
New subject: Changes to .jsp in an exploded deployment no longer picked up?
From: "Jim Tyrrell" <jtyrrell(a)redhat.com>
To: "Andrig Miller" <anmiller(a)redhat.com>
Cc: "jboss-as7-dev(a)lists.jboss.org Development"
<jboss-as7-dev(a)lists.jboss.org>
Sent: Tuesday, April 26, 2011 8:53:33 AM
Subject: Re: [jboss-as7-dev] Changes to .jsp in an exploded deployment no longer picked
up?
Andy,
So if AS 7 is more development focused, I agree it can/should be, can any and all
decisions made/discussed/etc on this list, make that experience the best it can be. Yes, I
would say so.
Worrisome threads in the last week:
Should a welcome page exist Being taken care of though, right.
Should it be enabled to have a .jsp to be hot deployed Looks like David Lloyd has this in
the right track.
How should lifecyles of datasource deployments be "configured/monitored/changed"
That discussion looks like it is also headed in the right direction.
On a side vein I still worry about adoption and the learning curve of all of this new
amazing stuff. I think we all do, and I think one of the things that we need to do is all
of us get the message out there for people to download, and test out Beta 3 and 4, and see
how many eyes we can get on it.
Probably a few others, but those have been on my mind this week.
Jim Tyrrell
Senior JBoss Solutions Architect
Did you see RHT on CNBC's Mad Money?
http://www.cnbc.com/id/39401056
On Apr 26, 2011, at 8:46 AM, Andrig Miller wrote:
From: "Jim Tyrrell" < jtyrrell(a)redhat.com >
To: " jboss-as7-dev(a)lists.jboss.org Development" <
jboss-as7-dev(a)lists.jboss.org >
Sent: Tuesday, April 26, 2011 7:56:11 AM
Subject: Re: [jboss-as7-dev] Changes to .jsp in an exploded deployment no longer picked
up?
My two cents,
As we do today, I am thinking you need to have configs out of the box that can be started.
Production
Development
Maybe even JMS
or WS
or....
I think prepackaged tested configs are a good idea as one size will not fit all. We have
done this for a long time and am wondering out loud why that notion would be removed?
There is a requirement in the PRD to have a development configuration and a production
configuration, but that is specific to EAP. Traditionally, we have made the AS
distribution more "development" focused out-of-the-box.
I'm not sure, in this specific case what is the best option, but EAP will have a
production and development configuration (perhaps a script that sets things up for either
using the management API).
Andy
Jim Tyrrell
Senior JBoss Solutions Architect
Did you see RHT on CNBC's Mad Money?
http://www.cnbc.com/id/39401056
On Apr 26, 2011, at 7:39 AM, ssilvert(a)redhat.com wrote:
Quoting Jaikiran Pai < jpai(a)redhat.com >:
Thinking a bit more about this, I don't see any use of supporting
exploded deployments (out of the box) if we don't support dynamic
changes to .jsps (out of the box). What else can be changed dynamically
in an exploded deployment?
xhtml (Facelets) pages can behave the same as JSP's as long as you are
in development mode.
-Jaikiran
On Tuesday 26 April 2011 04:52 PM, Remy Maucherat wrote:
On Tue, 2011-04-26 at 16:40 +0530, Jaikiran Pai wrote:
The better default will now be used: development will remain as "false".
IMO, before going to production with the server, any developer/team
would go through a development phase in which he would definitely like
this feature. So having this turned on by default (atleast in standalone
mode), IMO, makes sense.
P.S: I created https://issues.jboss.org/browse/AS7-659 and was about to
send out a pull request with a patch, before I saw this reply. If
there's any objection to this change, then I'll wait for a resolution on
this discussion.
I have rejected the jira.
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
10:03 a.m.
New subject: Changes to .jsp in an exploded deployment no longer picked up?
The eyes that we are getting on the betas - are they purely random
developers or do we have any customers with their developers looking at
it and how it affects their enterprise?
I know <#-- name was commented out --> has been looking at AS7 from a deployment
perspective
and they really dig that, but I haven't heard much from their developers
regarding AS7. Do we have any customers helping drive AS7 and what are
they saying? If that is out in the community forums, my apologies for
not seeing it.
On 04/26/2011 09:56 AM, Andrig Miller wrote:
------------------------------------------------------------------------
*From: *"Jim Tyrrell" <jtyrrell(a)redhat.com>
*To: *"Andrig Miller" <anmiller(a)redhat.com>
*Cc: *"jboss-as7-dev(a)lists.jboss.org Development"
<jboss-as7-dev(a)lists.jboss.org>
*Sent: *Tuesday, April 26, 2011 8:53:33 AM
*Subject: *Re: [jboss-as7-dev] Changes to .jsp in an exploded
deployment no longer picked up?
Andy,
So if AS 7 is more development focused, I agree it can/should be,
can any and all decisions made/discussed/etc on this list, make
that experience the best it can be.
Yes, I would say so.
Worrisome threads in the last week:
Should a welcome page exist
Being taken care of though, right.
Should it be enabled to have a .jsp to be hot deployed
Looks like David Lloyd has this in the right track.
How should lifecyles of datasource deployments be
"configured/monitored/changed"
That discussion looks like it is also headed in the right direction.
On a side vein I still worry about adoption and the learning curve
of all of this new amazing stuff.
I think we all do, and I think one of the things that we need to do is
all of us get the message out there for people to download, and test
out Beta 3 and 4, and see how many eyes we can get on it.
Probably a few others, but those have been on my mind this week.
Jim Tyrrell
Senior JBoss Solutions Architect
Did you see RHT on CNBC's Mad Money?
http://www.cnbc.com/id/39401056
On Apr 26, 2011, at 8:46 AM, Andrig Miller wrote:
------------------------------------------------------------------------
*From:*"Jim Tyrrell" <jtyrrell(a)redhat.com
<mailto:jtyrrell@redhat.com>>
*To:*"jboss-as7-dev@lists.jboss.org
<mailto:jboss-as7-dev@lists.jboss.org>Development"
<jboss-as7-dev(a)lists.jboss.org
<mailto:jboss-as7-dev@lists.jboss.org>>
*Sent:*Tuesday, April 26, 2011 7:56:11 AM
*Subject:*Re: [jboss-as7-dev] Changes to .jsp in an
exploded deployment no longer picked up?
My two cents,
As we do today, I am thinking you need to have configs out
of the box that can be started.
Production
Development
Maybe even JMS
or WS
or....
I think prepackaged tested configs are a good idea as one
size will not fit all. We have done this for a long time
and am wondering out loud why that notion would be removed?
There is a requirement in the PRD to have a development
configuration and a production configuration, but that is
specific to EAP. Traditionally, we have made the AS
distribution more "development" focused out-of-the-box.
I'm not sure, in this specific case what is the best option,
but EAP will have a production and development configuration
(perhaps a script that sets things up for either using the
management API).
Andy
Jim Tyrrell
Senior JBoss Solutions Architect
Did you see RHT on CNBC's Mad Money?
http://www.cnbc.com/id/39401056
On Apr 26, 2011, at 7:39 AM,ssilvert(a)redhat.com
<mailto:ssilvert@redhat.com>wrote:
Quoting Jaikiran Pai <jpai(a)redhat.com
<mailto:jpai@redhat.com>>:
Thinking a bit more about this, I don't see any
use of supporting
exploded deployments (out of the box) if we don't
support dynamic
changes to .jsps (out of the box). What else can
be changed dynamically
in an exploded deployment?
xhtml (Facelets) pages can behave the same as JSP's as
long as you are
in development mode.
-Jaikiran
On Tuesday 26 April 2011 04:52 PM, Remy Maucherat
wrote:
On Tue, 2011-04-26 at 16:40 +0530, Jaikiran
Pai wrote:
The better default will now be used:
development will remain as "false".
IMO, before going to production with the
server, any developer/team
would go through a development phase in
which he would definitely like
this feature. So having this turned on by
default (atleast in standalone
mode), IMO, makes sense.
P.S: I
createdhttps://issues.jboss.org/browse/AS7-659and
was about to
send out a pull request with a patch,
before I saw this reply. If
there's any objection to this change, then
I'll wait for a resolution on
this discussion.
I have rejected the jira.
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
<mailto:jboss-as7-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
<mailto:jboss-as7-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
<mailto:jboss-as7-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
11:25 a.m.
On Tue, Apr 26, 2011 at 9:03 AM, Joel Tosi wrote:
The eyes that we are getting on the betas - are they purely random
developers or do we have any customers with their developers looking at it
and how it affects their enterprise?
I know StateFarm has been looking at AS7 from a deployment perspective and
they really dig that, but I haven't heard much from their developers
regarding AS7. Do we have any customers helping drive AS7 and what are they
saying? If that is out in the community forums, my apologies for not seeing
it.
I'm not a customer, per se, but I do use JBoss for a few of my
production deployments.
I'm loving AS7. I'm a dev and an admin, and there's compelling stuff
going on in both those areas.
As far as the "default to development" or "default to production"
debate, I say (not that it matters) default to bare bones production,
and provide configs for various scenarios (similar to previous
releases, but with a bit more variety perhaps).
I'd rather have security out of the box, than comfort.
I'm not advocating no docs and hard to find configuration parameters,
by any means. I just think putting things in a less-than-secure (and
slower) mode should be the onus of the developer/end user, vs. coming
that way out of the box.
I acknowledge that I'm probably in the minority here, but especially
with a release as blazingly fast as AS7 currently is, it'd be a shame
to hide that away by default.
What's the "image" for AS7? Like, it's been pretty enterprise-y, but
it sounds like there's a move towards "Hey, it's for everybody!" type
of deal.
If I'm some random JEE guy, I'll probably be all like, "it's that much
faster, really? I'm gonna drop my WAR (is that like, soo 2004? ;]) in
there and see!", but I dunno what the target demographic is. People
new to JEE?, people new to AS7?, Developers?, Admins?, people X? What
are the main targets with AS7? "All of them" is swell, but hard to do
well. =)
I applaud the effort at "all of 'em". It is doable, IMHO. But I *am*
an optimist (mostly).
:Denny
--
The word experience is like a shrapnel shell, and bursts into a
thousand meanings.
George Santayana
9:08 a.m.
Am 26.04.2011 um 13:10 schrieb Jaikiran Pai:
IMO, before going to production with the server, any developer/team
would go through a development phase in which he would definitely like
this feature. So having this turned on by default (atleast in standalone
We could have a 'development' profile, that has all the development
bells and whistles enabled (like this one) I think there also was a thread
about xml validation, that could be enabled in that dev profile and disabled
otherwise (?)
Heiko
6:17 a.m.
On Tuesday 26 April 2011 04:35 PM, Remy Maucherat wrote:
The domain is a centralized config, fully documented, dynamic, so it
should more practical to use than the previous files. I understand
there's an initial learning period, but it should be worth it.
(My reply here isn't really specific to this issue but more towards the
changes that we do in AS7)
I do realize that AS7 is drastically different from previous versions
and we are trying to do our best to get it right. At the same time, I'm
sure many of us realize that, for various reasons from a user/developer
point of view, migrating to AS7 isn't going to be a straightforward
task. So I think, wherever possible (like this case), we should make it
easier for users to feel at home while using AS7 instead of adding to
their learning list yet another server specific configuration.
-Jaikiran
6:49 a.m.
On Tue, 2011-04-26 at 12:35 +0200, Max Rydahl Andersen wrote:
> a +1000's...since finding all those development flags is going to be impossible
> if that trend continues of having subsystem specific flags for this.
The better default will now be used: development will remain as "false".
Development is very expensive performance wise, and is not TCK
compliant.
I'm sorry but that makes no sense to me.
You would rather have the server out of the box be TCK compliant
than usable for development ? I thought we were pass the mistakes
made in latest AS and EAP being targeted purely for production ?
The domain is a centralized config, fully documented, dynamic, so it
should more practical to use than the previous files. I understand
there's an initial learning period, but it should be worth it.
I'm sorry, but that's just not making sense to me.
And btw. where is the documentation for that AS 7 setting ?
And which other flags need to be enabled for other subsystems to have
"development"
enabled ?
/max
http://about.me/maxandersen
7:17 a.m.
On Tue, 2011-04-26 at 13:49 +0200, Max Rydahl Andersen wrote:
You would rather have the server out of the box be TCK compliant
than usable for development ? I thought we were pass the mistakes
made in latest AS and EAP being targeted purely for production ?
The dev scenario I described using a marker (or the equivalent API call
to trigger a redeploy) seems far more sustainable, even if it takes a
bit more time (framework init, etc).
> The domain is a centralized config, fully documented, dynamic,
so it
> should more practical to use than the previous files. I understand
> there's an initial learning period, but it should be worth it.
I'm sorry, but that's just not making sense to me.
And btw. where is the documentation for that AS 7 setting ?
And which other flags need to be enabled for other subsystems to have
"development"
enabled ?
JSP is a bit specific, and I explained why.
Hopefully. Development mode for JSPs is a relic of the past, deprecated
if you prefer. So it is enabled back using a flag, for the folks that
were really in love with it back then, and still use straight JSPs. This
flag is JSP specific. Looking at your new email: facelets are not JSPs.
--
Remy Maucherat <rmaucher(a)redhat.com>
Red Hat Inc
10:11 a.m.
I know this thread, but I think it's worth correcting a misconception here.
On 26 Apr 2011, at 08:17, Remy Maucherat wrote:
On Tue, 2011-04-26 at 13:49 +0200, Max Rydahl Andersen wrote:
> You would rather have the server out of the box be TCK compliant
> than usable for development ? I thought we were pass the mistakes
> made in latest AS and EAP being targeted purely for production ?
The dev scenario I described using a marker (or the equivalent API call
to trigger a redeploy) seems far more sustainable, even if it takes a
bit more time (framework init, etc).
Application developers do not care about sustainability. They care about turnaround and
development time.
Operations guys care about sustainability.
This update-without-redeploy stuff is really important, and I've seen this
misunderstanding before with concerns like "well the update will not always
succeed" - in development this does not matter one bit. If it the update fails, you
simply restart the AS and it starts working again.
3:14 p.m.
+a million
On May 5, 2011, at 11:11, Pete Muir wrote:
I know this thread, but I think it's worth correcting a
misconception here.
On 26 Apr 2011, at 08:17, Remy Maucherat wrote:
> On Tue, 2011-04-26 at 13:49 +0200, Max Rydahl Andersen wrote:
>> You would rather have the server out of the box be TCK compliant
>> than usable for development ? I thought we were pass the mistakes
>> made in latest AS and EAP being targeted purely for production ?
>
> The dev scenario I described using a marker (or the equivalent API call
> to trigger a redeploy) seems far more sustainable, even if it takes a
> bit more time (framework init, etc).
Application developers do not care about sustainability. They care about turnaround and
development time.
Operations guys care about sustainability.
This update-without-redeploy stuff is really important, and I've seen this
misunderstanding before with concerns like "well the update will not always
succeed" - in development this does not matter one bit. If it the update fails, you
simply restart the AS and it starts working again.
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
/max
http://about.me/maxandersen
4:19 p.m.
and if it fails with a really great error message, like "you updated a component
which can not be at runtime restarted, please restart you instance" You would win
the prize for best usability ever. ;)
Jim Tyrrell
Senior JBoss Solutions Architect
Did you see RHT on CNBC's Mad Money?
http://www.cnbc.com/id/39401056
On May 5, 2011, at 9:11 AM, Pete Muir wrote:
I know this thread, but I think it's worth correcting a
misconception here.
On 26 Apr 2011, at 08:17, Remy Maucherat wrote:
> On Tue, 2011-04-26 at 13:49 +0200, Max Rydahl Andersen wrote:
>> You would rather have the server out of the box be TCK compliant
>> than usable for development ? I thought we were pass the mistakes
>> made in latest AS and EAP being targeted purely for production ?
>
> The dev scenario I described using a marker (or the equivalent API call
> to trigger a redeploy) seems far more sustainable, even if it takes a
> bit more time (framework init, etc).
Application developers do not care about sustainability. They care about turnaround and
development time.
Operations guys care about sustainability.
This update-without-redeploy stuff is really important, and I've seen this
misunderstanding before with concerns like "well the update will not always
succeed" - in development this does not matter one bit. If it the update fails, you
simply restart the AS and it starts working again.
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
7:07 a.m.
Is someone working on this or do we have a JIRA? If not, should I (re)
open a JIRA for this?
-Jaikiran
On Thursday 05 May 2011 08:41 PM, Pete Muir wrote:
I know this thread, but I think it's worth correcting a
misconception here.
On 26 Apr 2011, at 08:17, Remy Maucherat wrote:
> On Tue, 2011-04-26 at 13:49 +0200, Max Rydahl Andersen wrote:
>> You would rather have the server out of the box be TCK compliant
>> than usable for development ? I thought we were pass the mistakes
>> made in latest AS and EAP being targeted purely for production ?
>
> The dev scenario I described using a marker (or the equivalent API call
> to trigger a redeploy) seems far more sustainable, even if it takes a
> bit more time (framework init, etc).
Application developers do not care about sustainability. They care about turnaround and
development time.
Operations guys care about sustainability.
This update-without-redeploy stuff is really important, and I've seen this
misunderstanding before with concerns like "well the update will not always
succeed" - in development this does not matter one bit. If it the update fails, you
simply restart the AS and it starts working again.
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
6:29 a.m.
On Thursday 26 May 2011 05:51 PM, Remy Maucherat wrote:
On Thu, 2011-05-26 at 17:37 +0530, Jaikiran Pai wrote:
> Is someone working on this or do we have a JIRA? If not, should I (re)
> open a JIRA for this?
I will never allow this change to go in.
I read this entire thread again to try and understand why this is being
opposed. I see a couple of reasons, none of which I understand:
1) One of the reasons being mentioned is that enabling the option to
detect runtime .jsp changes breaks the TCK/spec. However, I don't know
what exactly this breaks? Can someone tell me what that is? If it breaks
some spec compliance then the rest of my arguments are irrelevant and
I'll stop asking for this flag to be enabled.
2) Enabling the option to detect runtime .jsp changes is bad for
performance. The suggested workaround is to redeploy the application,
which really doesn't make sense because that's worst if we are talking
about a developer's productivity. It's already been mentioned that the
community edition of JBoss AS is meant for developers and is _not_ meant
for direct production use. A application has to go through numerous
development lifecycles before it makes it to production (I didn't want
to state the obvious, but...).
Ultimately, this flag directly affects the end users (application
developers) and I think we should atleast take their opinion into
account before deciding not to allow this change. I'm sure that even if
we ship this as disabled, out of the box, a vast majority of the users
will end up enabling this flag as a first step during the development
lifecycle of their application.
Just to reiterate, I don't mind disabling this flag by default, if
there's a real valid reason for that. So far, I haven't seen any.
-Jaikiran
6:39 a.m.
On Fri, 2011-05-27 at 16:59 +0530, Jaikiran Pai wrote:
Just to reiterate, I don't mind disabling this flag by default,
if
there's a real valid reason for that. So far, I haven't seen any.
Bad performance + different behavior = it won't get in.
Now, I would have some sympathy if JSP was not being singled out among
the equivalent technologies, which are all running in production mode,
because you happen to use that for you hack testing. So change the
configuration, move on with your work, and stop wasting both of our
time. Thanks.
I'm ok if someone proposes a "master" development flag BTW.
--
Remy Maucherat <rmaucher(a)redhat.com>
Red Hat Inc
7:27 a.m.
On 05/27/2011 06:39 AM, Remy Maucherat wrote:
On Fri, 2011-05-27 at 16:59 +0530, Jaikiran Pai wrote:
> Just to reiterate, I don't mind disabling this flag by default, if
> there's a real valid reason for that. So far, I haven't seen any.
Bad performance + different behavior = it won't get in.
Now, I would have some sympathy if JSP was not being singled out among
the equivalent technologies, which are all running in production mode,
because you happen to use that for you hack testing. So change the
configuration, move on with your work, and stop wasting both of our
time. Thanks.
I'm ok if someone proposes a "master" development flag BTW.
I may be wrong, but I believe that JSP is singled out because every
other resource type (other than classes of course) already behaves this
way when you have an exploded deployment.
--
- DML
5:34 p.m.
Has anyone measured what is the true overhead of enabling it by default, anyway?
On 27/05/2011 15:27, David M. Lloyd wrote:
On 05/27/2011 06:39 AM, Remy Maucherat wrote:
> On Fri, 2011-05-27 at 16:59 +0530, Jaikiran Pai wrote:
>> Just to reiterate, I don't mind disabling this flag by default, if
>> there's a real valid reason for that. So far, I haven't seen any.
>
> Bad performance + different behavior = it won't get in.
>
> Now, I would have some sympathy if JSP was not being singled out among
> the equivalent technologies, which are all running in production mode,
> because you happen to use that for you hack testing. So change the
> configuration, move on with your work, and stop wasting both of our
> time. Thanks.
>
> I'm ok if someone proposes a "master" development flag BTW.
I may be wrong, but I believe that JSP is singled out because every
other resource type (other than classes of course) already behaves this
way when you have an exploded deployment.
2:55 a.m.
On Wed, 2011-06-01 at 01:34 +0300, Dimitris Andreadis wrote:
Has anyone measured what is the true overhead of enabling it by
default, anyway?
Dev mode:
- leaks details about the JSP source to give info on where and why the
error occurred (that's insecure, but important for dev)
- wraps exceptions for the same reason (TCK will fail)
- uses more memory (bad)
- uses a little bit more CPU (very little, so not bad)
I could enable some background reloading with fewer side effects, but
without the error reporting, it wouldn't help developers much.
So the domain model is a nice configuration format, well documented
(hopefully), so I think people will be fine using it and should be able
to configure this dev mode if they need it.
--
Remy Maucherat <rmaucher(a)redhat.com>
Red Hat Inc
7:26 a.m.
On Tue, 2011-04-26 at 14:21 +0200, Thomas Heute wrote:
On 04/26/2011 01:49 PM, Max Rydahl Andersen wrote:
> And which other flags need to be enabled for other subsystems to have
"development"
> enabled ?
>
Was wondering the same here...
It is called "development" because that's the name of the init-param
that has been used by the Jasper servlet, starting in 1999. Other
subsystems will likely not have a dev flag. As it is in the
jsp-configuration portion, I think it should be obvious this is JSP
specific.
--
Remy Maucherat <rmaucher(a)redhat.com>
Red Hat Inc
9:43 a.m.
On 04/26/2011 02:26 PM, Remy Maucherat wrote:
On Tue, 2011-04-26 at 14:21 +0200, Thomas Heute wrote:
> On 04/26/2011 01:49 PM, Max Rydahl Andersen wrote:
>> And which other flags need to be enabled for other subsystems to have
"development"
>> enabled ?
>>
>
> Was wondering the same here...
It is called "development" because that's the name of the init-param
that has been used by the Jasper servlet, starting in 1999.
Name is fine, problem is configuration + default
Other
subsystems will likely not have a dev flag.
This is where I am not that sure, portal will need one, we already have
such a flag to not cache built resources. I'm sure some other parts will
also want to make a distinction.
As it is in the
jsp-configuration portion, I think it should be obvious this is JSP
specific.
It is obvious, it's not the problem. The problem is to be user friendly.
I don't want to tell my users that to be able to do quick turnaround
development they have to:
- enable the JSP development flag...
- enable the GateIn development flag...
- enable the xyz development flag...
It's good to be able to "fine-tune" but would be nice to share a flag
too IMO.
Thomas
9:46 a.m.
On 04/26/2011 09:43 AM, Thomas Heute wrote:
On 04/26/2011 02:26 PM, Remy Maucherat wrote:
> On Tue, 2011-04-26 at 14:21 +0200, Thomas Heute wrote:
>> On 04/26/2011 01:49 PM, Max Rydahl Andersen wrote:
>>> And which other flags need to be enabled for other subsystems to have
"development"
>>> enabled ?
>>>
>>
>> Was wondering the same here...
>
> It is called "development" because that's the name of the init-param
> that has been used by the Jasper servlet, starting in 1999.
Name is fine, problem is configuration + default
> Other
> subsystems will likely not have a dev flag.
This is where I am not that sure, portal will need one, we already have
such a flag to not cache built resources. I'm sure some other parts will
also want to make a distinction.
> As it is in the
> jsp-configuration portion, I think it should be obvious this is JSP
> specific.
It is obvious, it's not the problem. The problem is to be user friendly.
I don't want to tell my users that to be able to do quick turnaround
development they have to:
- enable the JSP development flag...
- enable the GateIn development flag...
- enable the xyz development flag...
It's good to be able to "fine-tune" but would be nice to share a flag
too IMO.
It shouldn't be a global setting at all. It should be per-deployment
and it should default to "on" when there is exploded content and "off"
otherwise. In other words: the user should never even need to know
about it.
--
- DML
9:50 a.m.
On Tue, 2011-04-26 at 09:46 -0500, David M. Lloyd wrote:
It shouldn't be a global setting at all. It should be
per-deployment
and it should default to "on" when there is exploded content and
"off"
otherwise. In other words: the user should never even need to know
about it.
Ok, since I strongly disagree, I'll let you make that change.
--
Remy Maucherat <rmaucher(a)redhat.com>
Red Hat Inc
1:24 p.m.
>> As it is in the
>> jsp-configuration portion, I think it should be obvious this is JSP
>> specific.
>
> It is obvious, it's not the problem. The problem is to be user friendly.
> I don't want to tell my users that to be able to do quick turnaround
> development they have to:
> - enable the JSP development flag...
> - enable the GateIn development flag...
> - enable the xyz development flag...
>
> It's good to be able to "fine-tune" but would be nice to share a flag
> too IMO.
It shouldn't be a global setting at all. It should be per-deployment
and it should default to "on" when there is exploded content and
"off"
otherwise. In other words: the user should never even need to know
about it.
sounds awesome and I assume users can set it if they want it enabled for more specific
cases.
/max
http://about.me/maxandersen
4924
days inactive
4965
days old
38 comments
13 participants
participants (13)
-
Andrig Miller -
David M. Lloyd -
denstar -
Dimitris Andreadis -
Heiko W.Rupp -
Jaikiran Pai -
Jim Tyrrell -
Joel Tosi -
Max Rydahl Andersen -
Pete Muir -
Remy Maucherat -
ssilvert＠redhat.com -
Thomas Heute