Remove JSF 1.2 in AS8?
by ssilvert＠redhat.com
Does anyone object to the removal of JSF 1.2 in AS8? It was originally
shipped with AS7 to facilitate Seam 2.x apps that were incompatible with
JSF 2.x.
If it is removed in AS8 then you can still run these apps by adding JSF
1.2 back via the Multi-JSF feature or by using WAR_BUNDLES_JSF_IMPL.
Any thoughts?
Stan
12 years, 10 months
Cleaning up JBoss Metadata
by Stuart Douglas
Hi Guys,
Now that we have started on AS8 I would like to clean up JBoss Metadata,
and get rid of some of the legacy stuff that has accumulated over the years.
Basically I would like to branch 7.x for AS7 bug fixes, and start on
version 8.0 in master.
The changes I want to make are basically:
- Run a code formatter over the whole code base, and setup checkstyle rules
- Delete all the dead code, that is no longer relevant
- Flatten some of the inheritance hierarchies that are a relic from the
JAXB parsing days
- Fix or delete the ignored tests
Nothing major, but I just think that it will make the code more
maintainable going forward.
I have made a start here:
https://github.com/stuartwdouglas/metadata/compare/master
Can anyone see any problems with this approach?
If not, I will go ahead with this.
Stuart
12 years, 10 months
Creating a Web Common Module
by Stuart Douglas
Hi Guys,
Now that AS8 is starting I would like to move some classes out of the
web module, and into a web-common module, to allow subsystems to
integration with the web container without a direct dependency on the
web subsystem, the eventual goal being to support multiple web servers.
The changes I am proposing are in my web-common brach, and they are not
100% complete yet (In particular they do not address web services or
OSGI yet, as these rely on internal JBoss Web classes):
https://github.com/stuartwdouglas/jboss-as/compare/web-common
The main problem that I can see with this approach is that it moves the
WarMetaData class, which 3rd party extensions may be relying on. Given
that AS8 is a planned major release and will probably contain quite a
lot of breaking changes from an extension point of view, I don't think
this is a huge problem.
Thoughts?
Stuart
12 years, 10 months
Xalan custom jbossorg release
by Jan J. Roman
Hello everyone,
I can not get heard on irc ;-) and forum discussion in development area
seems to be a bit dead.
I would like to start contributing and I have been trying to resolve issue
reported here: https://issues.jboss.org/browse/AS7-6390
I came to the point where I figured out that the issue is caused by
incorrectly picked TransformerFactory class (it is created as an instance
of org.apache.xalan.xsltc.trax.TransformerFactoryImpl instead
of com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl).
This instance incorectly performs transormation of wsdl inserting doubled
namespace definitions.
As it was reported by user this is not happening in Jboss EAP 6.0
I did some investigation and I found that it is caused by change in the
file:
https://github.com/jboss/xalan-j/blob/jboss_2_7_1/src/META-INF/services/j...
Change labeled: "Enable xslt" commit:
928a986054f4c67fcd0d62fabec908aa77fdd864
This file exist in xalan-2.7.1-jbossorg-1.jar and xalan-2.7.1-redhat-1.jar
but in redhat release it is unchanged.
When I revert this change locally - correct class is picked and double
namespaces do not occur.
Another consternation about this third party release is that in nexus
repository there is released JAR named: xalan-2.7.1-jbossorg-2 while there
is no such version on github. It should not be an issue as by default
current builds of AS 6,7 and 8 ;-) are picking xalan-2.7.1-jbossorg-1 but
it would be nice to have it sorted.
OTOH replacing xalan-2.7.1-jbossorg-1 with xalan-2.7.1-jbossorg-2 does not
solve the problem mentioned above.
I am interested to hear your views on the matter.
Kind regards
12 years, 10 months
Stricter checkstyle import check
by Tomaž Cerar
Hi,
For some time we considering enabling
UnusedImports<http://checkstyle.sourceforge.net/config_imports.html>but
in past checkstyle seemingly reported too much false positives for
imports that looked valid.
We are now enabling <https://github.com/jbossas/jboss-as/pull/4099>this
check in most strict way possible.
that means:
- it will complain when there are usual unused imports
- it will complain when there are imports that are used *only in
javadoc*comments.
the later is the controversial one, as many of us by default use imports
also for javadoc and some IDEs do that by default.
For example code like this:
import java.util.List;
...
/**
* @param a {@link List} for attributes
*/
..
would complain that java.util.List is not used in this class.
Proper javadoc in this case would be to use fully qualified class names
like:
/**
* @param a {@link java.util.List} for attributes
*/
this only applies if this import is only used in Javadoc not anywhere else.
This is a draconian change and will require some adjusting to but you can
set your IDE to always use FQN for classes in javadoc.
IDEA has support for this, for eclipse we have not found it yet...
One reason to be strict with javadocs is recent indecent [1] with product
recompile failure of CFNE after some package was renamed and import was
only in javadoc.
if full class name would be used Javadoc compilation would still work, but
javadoc reference would be wrong.
--
tomaz
[1] https://bugzilla.redhat.com/show_bug.cgi?id=912237
12 years, 10 months
Fwd: [Lift] Re: java.lang.VerifyError using Lift-2.5-M4 with Scala-2.10
by Galder Zamarreño
One of the many reasons why I love JBoss AS7 :))
Begin forwarded message:
> From: Galder Zamarreño <galder(a)zamarreno.com>
> Subject: Re: [Lift] Re: java.lang.VerifyError using Lift-2.5-M4 with Scala-2.10
> Date: February 20, 2013 9:14:36 AM GMT+01:00
> To: liftweb(a)googlegroups.com
> Reply-To: liftweb(a)googlegroups.com
>
> Those using Escalante will find that there's no need for any classloading workaround (or black magic) to solve the commons-codec issue.
>
> The problem I was facing was a simple user error where I was adding two different versions of commons-codec to the WAR file (again, transitive dependencies stabbing me in the back...)
>
> But, what it's nice about Escalante is that deployments work totally separate of the jars the server uses. In fact, JBoss Application Server 7 that sits beneath Escalante uses commons-codec 1.4 for some of its internal components, but this dependency never leaks into the deployments unless you force it through. So, by default, you'll never find server jars leaking into deployments.
>
> So, if you wanna avoid classloading nightmares, I'd highly recommend that you deploy Lift apps on Escalante :)
>
> On Saturday, 16 February 2013 20:14:26 UTC+1, Peter Petersson wrote:
> On 02/16/2013 05:09 PM, Richard Dallaway wrote:
>> Thank you Peter. The inverted class-loader is the behaviour I'd expect for a servlet container. Is it now more a question of why it ever worked, rather than why it doesn't work with 2.10? :-)
>
> Yea you could say that.
> The reason I did not tested with inverse-classloading from the beginning was that it did not make sense for the app to end up in a vastly different class loading scenario just because it was compiled with a different version of Scala (this is still a bit fuzzy)
>
> Inverse classloading should be avoided in a production environment as it affects all classes but it is a nice tool to have for finding out stuff like this :).
>
> The best workaround (and a acceptable one) for the problem is to use the following in the geronimo deployment plan.
>
> <sys:import-package> !org.apache.commons.codec*</sys:import-package>
> Note: This is the preferred replacement of the older hidden-classes filter stuff
>
> It will filter out the containers common codec so that the app will get hold of its own codec jar (in the war /lib/)
> Lift is currently using commons codec v1.6 in all builds.
>
> I have found two uses of common codec (v1.3) in the geronomo container
> * In the enterprise service bus stuff provided by the ServiceMix component
> * In Apache Felix Preferences Service (OSGI stuff, org.apache.felix.prefs-1.0.4.jar)
>
> The late is core stuff in Geronimo so that is probably the one interfering with the Scala 2.10 build
>
> best regards
> Peter Petersson
>
>
>> Richard
>>
>> 1 https://cwiki.apache.org/GMOxDOC22/classloading.html
>>
>> On 16 February 2013 11:56, Peter Petersson <peterss...(a)gmail.com> wrote:
>>
>> As you can see on the Geronimo list i have found a work around for Geronimo deployment.
>> However the solution I use may not be optimal in all situations so I hope someone in the Geronimo community will take a closer look.
>>
>> The way I resolved the deploy/start problem with the 2.10 build was to add the inverse-classloading [1] setting to geronimo's deployment descriptor.
>>
>> [1] http://geronimo.apache.org/schemas-3.0/docs/geronimo-module-1.2.xsd.html#...
>>
>> best regards
>> Peter Petersson
>>
>>
>>
>> On 02/16/2013 12:48 PM, Richard Dallaway wrote:
>>> Thanks for this - I'm currently trying to get some traction on the issue for Geronimo. I'm hoping what we find for that will help with this.
>>>
>>> Richard
>>>
>>> On 14 February 2013 09:28, Galder Zamarreño <gal...(a)zamarreno.com> wrote:
>>> Richard,
>>>
>>> I was able to replicate the issue with this repo:
>>> https://github.com/galderz/escalante/tree/t_rearch
>>>
>>> To reproduce:
>>>
>>> 1. Change Scala version in https://github.com/galderz/escalante/blob/t_rearch/pom.xml to 2.10
>>> 2. Do: mvn clean install -pl build
>>> 3. Either from IDE or command line, run this Arquillian test: https://github.com/galderz/escalante/blob/t_rearch/modules/lift/src/it/te...
>>>
>>> NOTE: Test uses embedded Escalante instance, so give it some hefty VM options and add correct log manager, i.e.
>>>
>>> -Xmx512m -XX:MaxPermSize=256m -Djava.util.logging.manager=org.jboss.logmanager.LogManager
>>>
>>> Cheers,
>>>
>>>
>>> On Wednesday, 13 February 2013 12:05:39 UTC+1, Richard Dallaway wrote:
>>> Thank you. My simple (non-Lift) app deploys OK under both those versions. I've also just tried the M4 lift_blank template and that deployed and ran OK under Tomcat 7.0.28 with Scala 2.10 under JDK 1.7.
>>>
>>> If you can get a github repo together that reproduces the problem, I'm happy to take a look. Just let me know.
>>>
>>> Richard
>>>
>>> On 13 February 2013 09:59, Andreas Joseph Krogh <and...(a)officenet.no> wrote:
>>> På onsdag 13. februar 2013 kl. 10:45:42, skrev Richard Dallaway <ric...(a)dallaway.com>:
>>> Thanks for that -- which Tomcat is that?
>>>
>>> I notice Geronimo use 7.0.27 but I've been using 7.0.35
>>>
>>> My standalone Tomcat is 7.0.28 and the tomcat7-maven-plugin-2.0 uses Tomcat-7.0.30
>>>
>>> --
>>> Andreas Joseph Krogh <and...(a)officenet.no> mob: +47 909 56 963
>>>
>>> Senior Software Developer / CTO - OfficeNet AS - http://www.officenet.no
>>> Public key: http://home.officenet.no/~andreak/public_key.asc
>>>
>>> --
>>> --
>>> Lift, the simply functional web framework: http://liftweb.net
>>> Code: http://github.com/lift
>>> Discussion: http://groups.google.com/group/liftweb
>>> Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code
>>>
>>> ---
>>> You received this message because you are subscribed to the Google Groups "Lift" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+u...(a)googlegroups.com.
>>>
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>>
>>>
>>> --
>>> --
>>> Lift, the simply functional web framework: http://liftweb.net
>>> Code: http://github.com/lift
>>> Discussion: http://groups.google.com/group/liftweb
>>> Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code
>>>
>>> ---
>>> You received this message because you are subscribed to the Google Groups "Lift" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+u...(a)googlegroups.com.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>>
>>>
>>> --
>>> --
>>> Lift, the simply functional web framework: http://liftweb.net
>>> Code: http://github.com/lift
>>> Discussion: http://groups.google.com/group/liftweb
>>> Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code
>>>
>>> ---
>>> You received this message because you are subscribed to the Google Groups "Lift" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+u...(a)googlegroups.com.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>>
>>
>> --
>> --
>> Lift, the simply functional web framework: http://liftweb.net
>> Code: http://github.com/lift
>> Discussion: http://groups.google.com/group/liftweb
>> Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code
>>
>> ---
>> You received this message because you are subscribed to the Google Groups "Lift" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+u...(a)googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>> --
>> --
>> Lift, the simply functional web framework: http://liftweb.net
>> Code: http://github.com/lift
>> Discussion: http://groups.google.com/group/liftweb
>> Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code
>>
>> ---
>> You received this message because you are subscribed to the Google Groups "Lift" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+u...(a)googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>
>
> --
> --
> Lift, the simply functional web framework: http://liftweb.net
> Code: http://github.com/lift
> Discussion: http://groups.google.com/group/liftweb
> Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code
>
> ---
> You received this message because you are subscribed to the Google Groups "Lift" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+unsubscribe(a)googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org
12 years, 10 months
