Re: [jboss-as7-dev] Changes to .jsp in an exploded deployment no longer picked up?
by Jason T. Greene
On 4/26/11 10:49 AM, ssilvert(a)redhat.com wrote:
> Quoting Remy Maucherat<rmaucher(a)redhat.com>:
>
>> 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.
>
> I also disagree, but for different reasons. Whether or not you run in
> development mode should not depend on exploded/unexploded. Some tools
> used in development would deploy unexploded. Development mode is used
> for more than just hot deploy of JSP and Facelets. It also determines
> what kind of error messages you see in the browser. So even if a
> developer isn't interested in JSP/Facelets hot deploy he would
> certainly want to see the error detail that development mode provides
> in the browser.
It sounds like this setting does too much. I mean it would be really
really silly to have a non-exploded deployment looking for jsp changes...
--
Jason T. Greene
JBoss, a division of Red Hat
13 years, 8 months
Re: [jboss-as7-dev] Changes to .jsp in an exploded deployment no longer picked up?
by Max Rydahl Andersen
>
>> 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.
>
> I also disagree, but for different reasons. Whether or not you run in
> development mode should not depend on exploded/unexploded.
Why not by default ?
> Some tools
> used in development would deploy unexploded. Development mode is used
> for more than just hot deploy of JSP and Facelets. It also determines
> what kind of error messages you see in the browser. So even if a
> developer isn't interested in JSP/Facelets hot deploy he would
> certainly want to see the error detail that development mode provides
> in the browser.
But they would still be able to enable it specifically I assume ?
Note, I would prefer "development" mode is either enabled by default or controllable by a single startup flag
so there is a way to run in "fast development mode" without explaining how to locate the flag (or even worse multiple flags)
inside any xml.
> I think we simply need to decide if the default configuration for the
> community edition will be to set things to development mode the way we
> have traditionally done. I am in favor of that, at least for
> standalone.
+1
/max
13 years, 8 months
Re: [jboss-as7-dev] composite operations: error messages
by Brian Stansberry
I've opened https://issues.jboss.org/browse/AS7-669
On 4/26/11 10:49 AM, Heiko Braun wrote:
> I don't see any error details when composite op's fail.
> Is it just me or a general problem?
>
>
> [ERROR] Request
> [ERROR] {
> [ERROR] "operation" => "composite",
> [ERROR] "address" => [],
> [ERROR] "steps" => [
> [ERROR] {
> [ERROR] "operation" => "write-attribute",
> [ERROR] "address" => [
> [ERROR] ("host" => "local"),
> [ERROR] ("server-config" => "server-one")
> [ERROR] ],
> [ERROR] "name" => "socket-binding-group",
> [ERROR] "value" => "standard-sockets"
> [ERROR] },
> [ERROR] {
> [ERROR] "operation" => "write-attribute",
> [ERROR] "address" => [
> [ERROR] ("host" => "local"),
> [ERROR] ("server-config" => "server-one")
> [ERROR] ],
> [ERROR] "name" => "socket-binding-port-offset",
> [ERROR] "value" => 0
> [ERROR] }
> [ERROR] ],
> [ERROR] "child-type" => undefined
> [ERROR] }
> [ERROR]
> [ERROR] Response
> [ERROR]
> [ERROR] Internal Server Error
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
13 years, 8 months
Re: [jboss-as7-dev] Changes to .jsp in an exploded deployment no longer picked up?
by Andrig Miller
----- Original Message -----
> From: ssilvert(a)redhat.com
> To: jboss-as7-dev(a)lists.jboss.org
> Sent: Tuesday, April 26, 2011 9:49:58 AM
> Subject: Re: [jboss-as7-dev] Changes to .jsp in an exploded deployment no longer picked up?
> Quoting Remy Maucherat <rmaucher(a)redhat.com>:
>
> > 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.
>
> I also disagree, but for different reasons. Whether or not you run in
> development mode should not depend on exploded/unexploded. Some tools
> used in development would deploy unexploded. Development mode is used
> for more than just hot deploy of JSP and Facelets. It also determines
> what kind of error messages you see in the browser. So even if a
> developer isn't interested in JSP/Facelets hot deploy he would
> certainly want to see the error detail that development mode provides
> in the browser.
>
> I think we simply need to decide if the default configuration for the
> community edition will be to set things to development mode the way we
> have traditionally done. I am in favor of that, at least for
> standalone.
I agree completely. Standalone serves two purposes. The first being development, as a standalone server will be the most common way to do development. The second is for those users/customers that already have their own scripted management platform that they developed, and want to use that to do the management, versus going with our Domain model approach.
Andy
>
> >
> > --
> > Remy Maucherat <rmaucher(a)redhat.com>
> > Red Hat Inc
> >
> > _______________________________________________
> > 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
13 years, 8 months
DataSource Enable/disable
by Stefano Maestri
When John have changed datasources subsystem he have created 4
operations for them:
- add
- remove
- enable
- disable
I like them, now Heiko is asking to move enable/disable out in favour of
a more standard r/w attribute enabled (note that this attribute is
present in our xml). See There:
https://issues.jboss.org/browse/JBAS-9341
Since the operation don't just change the attribute, but also stop
services and unbind ds from jndi I'd prefer to keep operations as is. I
think an explicit operation make clearer to users that they are changing
the status of the entire datasourrce
opinions?
S.
13 years, 8 months
jboss-7.0.0.Beta3.zip download has some vi swp files in the standalone/configuration dir
by Scott Stark
I was editing the standalone.xml and saw the following warning about the
file being edited elsewhere:
E325: ATTENTION
Found a swap file by the name ".standalone.xml.swp"
owned by: root dated: Tue Apr 19 23:58:56 2011
file name:
~jason/devel/jboss-as/build/src/main/resources/standalone/co
nfiguration/standalone.xml
modified: no
user name: jason host name: guinness.local
process ID: 4902
While opening file "standalone.xml"
dated: Tue Apr 19 23:58:56 2011
I knew it was not possible for Jason to be doing so, so I checked the
original download and do see the swp files in there:
[112](ironmaiden:tmp) > unzip /home/svn/Makara/jboss-7.0.0.Beta3.zip
Archive: /home/svn/Makara/jboss-7.0.0.Beta3.zip
...
inflating:
jboss-7.0.0.Beta3/standalone/configuration/.standalone.xml.swo
inflating:
jboss-7.0.0.Beta3/standalone/configuration/.standalone.xml.swp
13 years, 8 months
JBAS-9373, need control of what interfaces/ports are bound to
by Scott Stark
I created this bug, now changed to an enhancement request:
https://issues.jboss.org/browse/JBAS-9373
to deal with the tm layer binding to an anonymous port on the 127.0.0.1
interface as a means to obtain a system wide unique number. How this is
done is not exposed via the domain model, and when running in an selinux
(secured linux) environment we need control over what interfaces/ports
are bound to, where files are written, etc. to be able to write the
correct selinux policy.
Do we need, or already have a id service that can be leveraged here? It
looks like the arjuna Uid class that is used generates a 28 byte/224 bit
value.
The main issue is that any subsystem has to express what privileged
resources it is making use of through the domain model.
13 years, 8 months
Collecting multiple exceptions from a batch operation and handling them...
by Scott Marlow
I have some JPA container level code that needs to close a set of entity
managers. each entity manager close operation could throw an exception.
Each thrown exception, could have a series of chained exceptions.
The simplest thing to do, would be to log each exception. Or to throw
the first exception and log the remaining ones. This can only happen
for non-transactional work (no database updates), so either approach is
fine.
Are we dealing with this anywhere else? I can take the same approach
used elsewhere if so.
Scott
13 years, 8 months
Datasource name - DefaultDS instead of H2DS?
by Jaikiran Pai
I see that we ship a datasource out of the box and is available at
java:/H2DS
12:59:31,816 INFO [org.jboss.as.connector.subsystems.datasources] (MSC
service thread 1-4) Bound JDBC Data-source [java:/H2DS]
Would it be better to make it available at java:/DefaultDS? I am sure
there are many quick start/example/demo applications out there which use
java:DefaultDS for such simple examples. It would make it easier to use
those examples in AS7, without having to change them, if we stick with
the older name. Thoughts?
-Jaikiran
13 years, 8 months
