Re: JBossAS 4.2.2.GA status
by Dimitris Andreadis
Then we should defer the resolution of JBAS-4852, JBWS-1813 for a future release.
Unless I hear differently I will be tagging the release on Wed morning.
Rajesh, we just want to verify that the TCK runs clean.
William DeCoste wrote:
> Both of the EJB3/WS (JBAS-4852,JBWS-1813) issues are related to
> processing metadata from xml - it's VERY broken. Thomas is making fixes
> in jbossws2.0.3. I doubt it will be complete in time for 4.2.2.
>
> -Bill
>
> Dimitris Andreadis wrote:
>> We are very close to tagging the AS 4.2.2.GA release.
>>
>> From the JIRA
>> http://jira.jboss.com/jira/secure/IssueNavigator.jspa?reset=true&mode=hid...
>>
>>
>> We performed a jbossxb upgrade from 1.0.0.GA to 1.0.0.SP1 for
>> http://jira.jboss.com/jira/browse/JBAS-4853
>>
>> This includes:
>> JBXB-97 org.w3c.dom.Element is being mapped incorrectly
>> JBXB-105 switch from oswego to java.util concurrent
>> JBXB-103 JBossXB ignores non-ignorable white space
>> JBXB-96 JAXB error when using different derived types in the same
>> container/array type
>>
>> I don't see any regressions in the testsuites.
>>
>> The only thing that is holding us is this:
>> http://jira.jboss.com/jira/browse/JBAS-4852
>> http://jira.jboss.com/jira/browse/JBWS-1813
>>
>> It needs to be either resolved ASAP, or deferred. Carlo and Thomas
>> cooperate on this task.
>>
>> TCK 1.4 should be fully passing now, but it is probably wise to do
>> another run just after JBAS-4852 is resolved/deferred and before
>> releasing.
>> http://jira.jboss.com/jira/browse/JBAS-4754
>>
>> There is also a task for including the jbossws testsuite in the AS
>> release process
>> http://jira.jboss.com/jira/browse/JBAS-4811
>>
>> For both QA tasks, Rajesh is our man.
>>
>> Let's finish with this release!
>>
>> Thanks
>> /Dimitris
>>
>>
>
17 years, 11 months
Interfere the .EntityManager actions in jboss
by Meir Yanovich
Hello all
We have very large application that use's extensively the EntityManager
methods (createNamedQuery, createQuery, find, merge)
Now to refractor all the instances will be a pain, my problem is
That I need to insert another check in the returned value and filter it
out
Can it be bone after the information send into the EntityManager?
18 years
Compiling JBoss Head with Java6
by Adrian Brock
I've got JBoss Head compiling with Java6.
I managed to avoid using a preprocessor for the JDBC rar
but only by using reflection to decide which
version of the code is in the classpath, i.e. JDK5/JDK6
The reflection is only done once. but
there is more duplicate code that there would otherwise be.
e.g. WrappedPreparedStatementJDK6 can't extend
both WrappedPreparedStatement and WrappedStatementJDK6 :-)
I haven't implemented the Wrapper interface fully.
This will need a revisit where it needs to "recursively"
check whether the object we wrap is itself a wrapper.
I also "commented out" the DataSourceInterceptor in varia.
I didn't convert it to JDK6.
As far as I can tell, this is not included in the distribution,
not even in docs/examples/varia.
Alex you wrote this what is happening with this?
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
18 years
Updating JIRA
by Thomas Diesler
Hi Folks,
who own the JIRA installation these days?
We are currently at 3.6.5 (18-Sep-2006). The latest is 3.11
(25-Sep-2007) and contains a number of fixes and features that I would
welcome (e.g. subtask to top-level and vise-versa)
cheers
-thomas
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
Web Service Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
18 years
com.sun.tools.javac.code.Symbol$CompletionFailure
by Anil Saldhana
Any clue what is happening here:
====================
compile-classes:
[javac] Compiling 57 source files to
C:\cygwin\home\asaldhana\jboss-5.0\jboss-head\security\output\classes
[javac]
C:\cygwin\home\asaldhana\jboss-5.0\jboss-head\security\src\main\org\
jboss\security\auth\login\DynamicLoginConfig.java:36: warning:
[deprecation] org
.jboss.deployment.DeploymentException in org.jboss.deployment has been
deprecate
d
[javac] import org.jboss.deployment.DeploymentException;
[javac] ^
[javac] An exception has occurred in the compiler (1.5.0_14). Please
file a
bug at the Java Developer Connection
(http://java.sun.com/webapps/bugreport) af
ter checking the Bug Parade for duplicates. Include your program and the
followi
ng diagnostic in your report. Thank you.
[javac] com.sun.tools.javac.code.Symbol$CompletionFailure: file
javax\xml\bi
nd\annotation\XmlType.class not found
BUILD FAILED
C:\cygwin\home\asaldhana\jboss-5.0\jboss-head\security\build.xml:194:
Compile fa
iled; see the compiler error output for details.
=====================================
All I did was import metadata classpath into the security workspace in
AS trunk.
18 years
Hudson runs broken
by Dimitris Andreadis
The hudson runs for anything AS related are taking hours to complete and eventually fail. It
went like this for the whole day yesterday and the problem is still there AFAICT. (e.g. a
simple JBoss-AS-5.0.x that would normally take 30' is now running for 6 hours).
Rajesh is telling me we are running out of disk space. When is this going to get fixed ???
Thanks
/Dimitris
18 years
Obtain Transaction Manager in AS Trunk?
by Anil Saldhana
With all the TM changes that has happened, what is the right way to get
an instance of TM?
org.jboss.transaction.TransactionManagerLocator.getInstance().locate() ?
Does the "java:/TransactionManager" JNDI binding still work to get hold
of the UT?
18 years
Does this seem like a compiler bug?
by Scott M Stark
I ran into a problem with the following code that compiles in eclipse,
but fails under the sun jdk:
public void testClassCollection()
{
Collection<Class<?>> c = null;
Collection<Class> ce = (Collection<Class>) c; // This is a warning
in eclipse, error under sun jdk.
This seems like an overly strict check. I can understand it for types
that allow mutable operations with respect to the wildcard parameter,
such as a Collection of List<?>:
public void testCollectionOfUknownlistAdd()
{
Collection<List<?>> coul = new ArrayList<List<?>>();
List<?> lw = coul.iterator().next();
// This is an error because don't know what ? is
lw.add(new Object());
Collection<List> col = (Collection<List>) coul;
List l = col.iterator().next();
// This is allowed for legacy usage
l.add(new Object());
}
but I don't see how I can unsafely use Class in place of Class<?>. Its
equivalent to this safe read-only usage of an unknown collection, which
eclipse does allow, but the jdk does not:
public void testCollectionOfUknownlistGet()
{
Collection<List<?>> coul = new ArrayList<List<?>>();
List<?> lw = coul.iterator().next();
// This is fine because ? although unknown, is still an Object
Object o1 = lw.get(0);
Collection<List> col = (Collection<List>) coul;
List l = col.iterator().next();
Object o2 = l.get(0);
}
18 years
Re: [jboss-dev] Apologize (was Usecase xml ...)
by Ke Jin
On 11/21/2007 05:03 AM, Adrian Brock wrote:
>On Wed, 2007-11-21 at 00:46 -0500, Ke Jin wrote:
>> It seems we have some communication problem. Let me clarify it again. I have
>never claimed using XSLT transformation to simplify XML configuration is my
>"just discovered idea". Because the key concept of this idea has been around
>for decades. I don't mind your yuck, neither care whoever want to claim it is
>their idea few years ago.
>
>You are correct we have a communication problem
>(many of them, I think :-).
>
>I claim that preprocessors are not the way to go.
>The model should be used by both the front end and backend.
>
>If you know of examples that don't use preprocessors
>but do bind models to implementations that "go back decades"
>I'd like to know about them to understand the lessons
>learned. :-)
>
>If however you are only talking about preprocessors then yes
>this hack has been around forever.
>
>e.g. if you've looked at the gcc code
>you write front ends and backends almost entirely in
>c macros.
>
>Why didn't they just define their own DSL? :-)
>
>>
>> [snip]
>>
>> >
>> >> Fourthly, for using the XSLT, please read my post and article closely
>(pay
>> >attention to "higher order transformation"). The XSLT is just used as the
>core
>> >schema for model transformation, because it is standardized and ubiquitous
>
>> >(therefore, would be easy for third party support). None-XSLT
>transformation
>> >stylesheet schema can certainly be supported, and already supported by
>> >PocoCapsule for C++.
>> >>
>
>I don't care whether the preprocessor is XSLT or
>some other transformation.
>
I don't care either. The issue here is, to clarify it again, I never claimed this is a "just discovered idea". That is the point.
[snip]
>
>
>By Programmatic, I mean the opposite of
>imperative. Everything that can be done
>with xml should be doable from a java
>program.
>
>i.e. You shouldn't force people to make the
>"paradigm shift" to IOC+DSM.
>
You have a very imaginative interpretation of "imperative programming"! I recommend you do a wiki search please and see what is the precise meaning of this term.
>They shouldn't have to create a DOM tree
>run it through an xslt before they can deploy a datasource
>like they have do in our current implementation. :-)
>
Is this your understanding (and your implementation, if any) on how to use XSLT? This (plus your understanding on "imperative programming" and your complaint of not able to do programmatic configuration in XSLT) explained everything. Thanks!
Ke
>> Cheers!
>> Ke
>>
>> >> Sincerely,
>> >> Ke
>> >> _______________________________________________
>> >> jboss-development mailing list
>> >> jboss-development(a)lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/jboss-development
>> >--
>> >xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>> >Adrian Brock
>> >Chief Scientist
>> >JBoss, a division of Red Hat
>> >xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>> >
>> >_______________________________________________
>> >jboss-development mailing list
>> >jboss-development(a)lists.jboss.org
>> >https://lists.jboss.org/mailman/listinfo/jboss-development
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
>--
>xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>Adrian Brock
>Chief Scientist
>JBoss, a division of Red Hat
>xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>
>_______________________________________________
>jboss-development mailing list
>jboss-development(a)lists.jboss.org
>https://lists.jboss.org/mailman/listinfo/jboss-development
18 years
