On demand JCA and JTA for the web-profile
by Adrian Brock
See:
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4189122#4189122
This will be the first real use of the "new" on-demand processing.
The idea is that unless the webapp looks up a user transaction
or transaction synchronization registry (there's a sticking point
there) or the admin deploys a transactional datasource,
then jca and jta won't bootstrap by default.
This won't effect the other configurations since we always provide
a transactional datasource out-of-the-box for jms persistence
and other services reference the transaction manager anyway
so they will always bootstrap.
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
16 years, 9 months
Continuing Maven migration
by Paul Gier
I'd like to continue with the Maven migration of the app server build. So
starting next week, I will be switching over one or two modules at a time in the
order that they are currently built.
So for example, the first to switch will be the "bootstrap" module followed by
the "main" module. The build/build.sh file will call maven to run the mavenized
modules first, and then continue with the non-mavenized modules. That way the
later modules can depend on the output of the earlier mavenized modules.
Once a module has been mavenized and is working without any issues, I will
remove the build.xml file from the directory, and you will have to build using
maven.
Please let me know of questions or concerns.
16 years, 11 months
Re: [jboss-dev] Re: Excessive logging in AS 4.2.3 and AS 5
by Jay Balunas
The threshold you're referring to should be the exception not the
rule. I'll admit I have not been following all of this closely, but I
thought the only reason we did not set logging to INFO by default was
because CI builds need to have DEBUG set.
I'm still confused why we don't just set a default value in log4j
config file for the log setting to INFO. Since I can see the need to
have a scriptable (i.e. command line) way to override for CI builds
the we can use the ability to override via command line ( which I
thought log4j supported anyway ).
Parting thoughts before the holidays ;-)
-Jay
On Dec 23, 2008, at 12:53 PM, Darran Lofthouse wrote:
>
> One drawback of this new Threshold is that to enable TRACE logging
> you are forced to set the property -
> Djboss.server.log.threshold=TRACE as even if this property is not
> set TRACE logging will be disabled just by the presence of this
> setting.
>
> Secondly I don't believe this is going to cause isDebugEnabled() to
> return false as the category is still set to the default so
> expensive operations wrapped by isDebugEnabled will still be called.
>
>
> Brian Stansberry wrote:
>> https://jira.jboss.org/jira/browse/JBAS-6205 is done.
>> Shelly, if there is going to be a new server-manager release, how
>> about we add a -Djboss.server.log.threshold=DEBUG to the args that
>> get passed when an AS is started? That's a quick way to ensure
>> testsuite configs launch with the correct level if we move the
>> default to INFO. Otherwise we'd have to figure out all projects
>> that use server-manager and edit their build file server:config
>> elements.
>> Jay Balunas wrote:
>>> OK thanks for the update. This property should make it very easy
>>> to adjust this for the test environment while still allowing us to
>>> ship AS5 in a configuration that does not created MBs of logs.
>>>
>>> On Nov 17, 2008, at 3:13 PM, Brian Stansberry wrote:
>>>
>>>> Jay Balunas wrote:
>>>>> ----- "Brian Stansberry" <brian.stansberry(a)redhat.com> wrote:
>>>>>> I see 3 different issues here:
>>>>>>
>>>>>> 1) Code that does per-request logging at DEBUG level instead of
>>>>>> TRACE.
>>>>>>
>>>>>> That's in violation of the logging standards and should be fixed.
>>>>> +1 and that is what we are seeing to some extent. We don't
>>>>> regularly need to known every time a class is loaded, or a
>>>>> persistence connection is closed.
>>>>>> 2) How much we log at DEBUG as part of service startup/
>>>>>> shutdown. IMHO, this is not a huge problem. We should probably
>>>>>> clean it up some, but
>>>>>>
>>>>>> the point of the logging is to make problem diagnosis easier,
>>>>>> not to produce small logs for infrequent events.
>>>>> Start up time in no little issue, but in general I agree. if
>>>>> there is extra logging during start up thats fine. The real
>>>>> issue is the reoccurring logs
>>>>>> 3) The default loggging level for server.log. If #1 is broken,
>>>>>> then having it be INFO makes sense, otherwise we punish users
>>>>>> for our problems. If #1 is fixed, then different people can
>>>>>> have different preferences, which I expect we're about to
>>>>>> debate here. :-) My
>>>>>> personal one is to leave it at DEBUG, unless we can make it
>>>>>> configurable via system property substitution. Otherwise all
>>>>>> testsuite runs will log
>>>>>> at INFO unless we introduce testsuite hacks to replace the
>>>>>> logging conf.
>>>>> IMO - I would like to see it at info, and use an ant command to
>>>>> adjust the debug level for hudson builds. Why punish our users
>>>>> so that the continuous builds log enough.
>>>>
>>>> Log4j supports a basic system property substitution, so the
>>>> server.log logging level can be controlled that way. I'll
>>>> selfishly add that -- since it will help Bela in some stuff he's
>>>> doing this week that in turn helps me. ;)
>>>>
>>>> https://jira.jboss.org/jira/browse/JBAS-6205
>>>>
>>>> Note that JBAS-6205 doesn't include changing the default to INFO.
>>>> I think INFO's fine, but it's not my call and in any case it's a
>>>> separate JIRA that involves some extra work (to get the
>>>> testsuites to log at DEBUG).
>>>>
>>>>
>>>> --
>>>> Brian Stansberry
>>>> Lead, AS Clustering
>>>> JBoss, a division of Red Hat
>>>> brian.stansberry(a)redhat.com
>>>
>
17 years, 1 month
AS5.x, AS6 roadmaps
by Scott Stark
We need to finalize the 3 month road map for AS5.x and its relation to
AS6. The current discussions have been around embedded and EE6 type
profiles and that we should focus on incorporating AS6 elements in the
next AS5.x release that improve the following areas:
* Unit Test Capabilities. The ability to embed JBoss inside unit tests
so that they can be run with no special plugins within an IDE, vanilla
maven testsuite, vanilla ant testsuite.
* Maven JBoss Plugin. You can define a configuration or override the
default. Basically making it nice and easy to use for maven people.
* Bundling of embedded jopr for the management console
* Get on-demand working for as many services as possible
* Optimize boot time (JBoss 5 boots much slower than JBoss 4.2)
* Deprecate and prune components and move them to a deprecated folder so
that they don't boot up with default config. (Web Console, JMX-Console,
Scheduler, EJB 2.x)
* Clean up service dependencies so its easier to add/remove components
and subsystems. This is related to on-demand as well.
* Define proper packaging of services so that dependencies and isolation
of implementation details exist.
* Profile service supporting subprofiles and proper repository
abstraction to allow for simple requirements descriptions of services in
a profile driving the post MC bootstrap loading of services.
17 years, 1 month
Re: JAXB
by Alexey Loubyansky
This doesn't sound right to me. Why don't you add the required/declared
dependencies?
Jesper Pedersen wrote:
> Hi Alexey.
>
> I don't know if you are the maintainer the JAXB files in repository.jboss.org,
> but there are classpath references in jaxb-impl-2.1.jar!/META-INF/MANIFEST.MF
>
> It would nice to have them removed, so I don't have to look at
>
> [javac] warning: [path] bad path
> element "..jboss-jca/trunk/lib/jaxb-api.jar": no such file or directory
> [javac] warning: [path] bad path
> element "../jboss-jca/trunk/lib/activation.jar": no such file or directory
> [javac] warning: [path] bad path
> element "../jboss-jca/trunk/lib/jsr173_1.0_api.jar": no such file or
> directory
> [javac] warning: [path] bad path
> element "../jboss-jca/trunk/lib/jaxb1-impl.jar": no such file or directory
>
> all the time ;)
>
> Attached version fixes all MANIFEST.MF problems...
>
> Keep pushing JBossXB, so I don't have to pull in this dependency :)
>
> Best regards,
> Jesper
17 years, 1 month
[JMX/Web Console] Possible bug in HtmlAdaptorServlet.updateAttributes()?
by Domenico Briganti
Hi all, I downloaded JBoss 5.0.0.GA and, without any changes, I tried to
modify one MBean from jmx-console but I received 500 Internal Server Error:
javax.management.MalformedObjectNameException: Key properties cannot be
empty
at javax.management.ObjectName.construct(ObjectName.java:467)
at javax.management.ObjectName.<init>(ObjectName.java:1403)
at
org.jboss.jmx.adaptor.control.Server.setAttributes(Server.java:171)
at
org.jboss.jmx.adaptor.html.HtmlAdaptorServlet$5.run(HtmlAdaptorServlet.java:
403)
at
org.jboss.jmx.adaptor.html.HtmlAdaptorServlet$5.run(HtmlAdaptorServlet.java:
401)
at java.security.AccessController.doPrivileged(Native Method)
at
org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.setAttributes(HtmlAdaptorServl
et.java:399)
at
org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.updateAttributes(HtmlAdaptorSe
rvlet.java:259)
at
org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.processRequest(HtmlAdaptorServ
let.java:102)
at
org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.doPost(HtmlAdaptorServlet.java
:86)
...
After debug, I think the problem is on HtmlAdaptorServlet.updateAttributes()
that tries to set MBean value without decode the string getted from
request.getParameter().
I modified the HtmlAdaptorServlet and inspectMBean.jsp in order to decode
parameter before update, and it's work!
That's the diff:
____________________________________________________________________________
__________
In inspectMBean.jsp
143c143
< <input type="button" value="Refresh MBean View"
onClick="javascript:location='HtmlAdaptor?action=inspectMBean&name=<%=
URLEncoder.encode(request.getParameter("name"),"UTF-8") %>'"/>
---
> <input type="button" value="Refresh MBean View"
onClick="javascript:location='HtmlAdaptor?action=inspectMBean&name=<%=
request.getParameter("name").indexOf("%") == -1 ?
URLEncoder.encode(request.getParameter("name"),"UTF-8") :
request.getParameter("name") %>'"/>
____________________________________________________________________________
__________
In HtmlAdaptorServlet.java
254c254
< attributes.put(param, value);
---
> attributes.put(param, URLDecoder.decode(value, "UTF-8"));
259,260c259,260
< AttributeList newAttributes = setAttributes(name, attributes);
< MBeanData data = getMBeanData(name);
---
> AttributeList newAttributes =
setAttributes(URLDecoder.decode(name, "UTF-8"), attributes);
> MBeanData data = getMBeanData(URLDecoder.decode(name, "UTF-8"));
____________________________________________________________________________
__________
Regards
Domenico Briganti
17 years, 1 month
Maven plugin - spellchecker for docs.
by Pete Muir
For those of you developing documentation:
https://www.jboss.org/community/docs/DOC-13212
Begin forwarded message:
> From: "Svetlana Mukhina" <smukhina(a)exadel.com>
> Date: 18 December 2008 14:54:12 GMT
> To: <abogachuk(a)exadel.com>, "'atsebro'" <atsebro(a)exadel.com>, <cluts(a)exadel.com
> >, <ggalkin(a)exadel.com>, "michael sorokin" <msorokin(a)exadel.com>, <ochikvina(a)exadel.com
> >, <smukhina(a)exadel.com>, "'tromanovich'" <tromanovich(a)exadel.com>
> Cc: 'richfaces-exadel' <richfaces-exadel(a)redhat.com>, external-exadel-list(a)redhat.com
> Subject: [Richfaces-exadel] RE: Maven plugin - spellchecker for docs.
>
> Hi,
> Spell checker plugin for docs is released
> (https://snapshots.jboss.org/maven2/org/jboss/maven/plugins/maven-spellCheck
> er-plugin/1.2-SNAPSHOT/), set and use it for guides as described here
> https://www.jboss.org/community/docs/DOC-13212, also plz add words for
> spell-checker to learn to this file
> https://svn.jboss.org/repos/richfaces/trunk/docs/common-resources/en/src/mai
> n/dictionaries/english.dic
>
> Thanks
>
> -----Original Message-----
> From: external-exadel-list-bounces(a)redhat.com
> [mailto:external-exadel-list-bounces@redhat.com] On Behalf Of Svetlana
> Mukhina
> Sent: Thursday, November 20, 2008 2:35 PM
> To: 'Max Rydahl Andersen'; 'Alexander Smirnov'
> Cc: external-exadel-list(a)redhat.com
> Subject: RE: Maven plugin - spellchecker for docs.
>
>
> Hi,
> We've put the plugin project here
> http://snapshots.jboss.org/maven2/org/jboss/maven/plugins/maven-spellChecker
> -plugin/
> And it works (:
>
> Not in RF repository, as then we would have to change lot's of paths
> and
> actually it's not only for RF docs but for JBDS and Tools as well.
>
> Thanks
>
> -----Original Message-----
> From: Max Rydahl Andersen [mailto:max.andersen@redhat.com]
> Sent: Wednesday, November 19, 2008 7:24 PM
> To: Alexandr Smirnov; Svetlana Mukhina
> Cc: external-exadel-list(a)redhat.com
> Subject: Re: Maven plugin - spellchecker for docs.
>
> ah you meant a svn repository - I thought you were just looking for a
> maven location ;)
>
> If it makes sense to have it in richfaces src without any richfaces
> dependencies then
> that is probably the easiest start.
>
> Otherwise we can just create a new project on jboss.org similar to the
> docbook styles project
> which Mark did.
>
> /max
>
>> You can put this plugin into RichFaces source code tree. Results of
>> the
>> RichFaces nigthly builds are always deployed into the Jboss snapshots
>> repository http://snapshots.jboss.org/maven2
>> Svetlana Mukhina wrote:
>>>
>>> Hi,
>>>
>>> We have working on maven plugin for guides spellchecking, now beta
>>> version is ready and we need some repository location to place it in
>>> and see how it will work from there, is there some sandbox for maven
>>> plugin test versions on jboss.org?
>>>
>>>
>>>
>>> Thanks
>>>
>>> ~~~
>>>
>>> Svetlana Mukhina
>>>
>>> Manager of Technical Writing Department, Exadel Inc.
>>>
>>> E-mail: smukhina(a)exadel.com <mailto:smukhina@exadel.com>
>>>
>>>
>>>
>>
>
>
>
> --
> /max
>
> _______________________________________________
> Richfaces-exadel mailing list
> Richfaces-exadel(a)redhat.com
> https://www.redhat.com/mailman/listinfo/richfaces-exadel
17 years, 1 month
