[Design of JBoss Web Services] - Hudson thirdparty downloads
by thomas.diesler＠jboss.com
For the last couple of runs Metro-Core-4.2.x had lots of regression which could not be reproduced locally
| [tdiesler@jbws jobs]$ find *-AS-4.2.?/workspace/stack-*/thirdparty -name jbossws-jboss42-resources.zip | xargs ls -l
| -rw-rw-r-- 1 tdiesler tdiesler 4767 Nov 20 18:32 AS-Tests-AS-4.2.1/workspace/stack-native/thirdparty/jbossws-jboss42-resources.zip
| -rw-rw-r-- 1 tdiesler tdiesler 4767 Nov 20 18:32 AS-Tests-AS-4.2.2/workspace/stack-native/thirdparty/jbossws-jboss42-resources.zip
| -rw-rw-r-- 1 tdiesler tdiesler 4767 Nov 20 18:32 AS-Tests-AS-4.2.3/workspace/stack-native/thirdparty/jbossws-jboss42-resources.zip
| -rw-rw-r-- 1 tdiesler tdiesler 4767 Mar 20 12:44 CXF-Distro-AS-4.2.2/workspace/stack-cxf/thirdparty/jbossws-jboss42-resources.zip
| -rw-rw-r-- 1 tdiesler tdiesler 4767 Mar 20 12:51 CXF-Distro-AS-4.2.3/workspace/stack-cxf/thirdparty/jbossws-jboss42-resources.zip
| -rw-rw-r-- 1 tdiesler tdiesler 4767 Mar 20 12:31 CXF-Integration-AS-4.2.2/workspace/stack-cxf/thirdparty/jbossws-jboss42-resources.zip
| -rw-rw-r-- 1 tdiesler tdiesler 4767 Mar 20 12:38 CXF-Integration-AS-4.2.3/workspace/stack-cxf/thirdparty/jbossws-jboss42-resources.zip
| -rw-rw-r-- 1 tdiesler tdiesler 5217 Mar 18 18:28 Metro-Core-AS-4.2.2/workspace/stack-metro/thirdparty/jbossws-jboss42-resources.zip
| -rw-rw-r-- 1 tdiesler tdiesler 5217 Mar 18 18:28 Metro-Core-AS-4.2.3/workspace/stack-metro/thirdparty/jbossws-jboss42-resources.zip
| -rw-rw-r-- 1 tdiesler tdiesler 4767 Nov 20 18:32 Metro-Distro-AS-4.2.2/workspace/stack-metro/thirdparty/jbossws-jboss42-resources.zip
| -rw-rw-r-- 1 tdiesler tdiesler 4767 Nov 20 18:32 Metro-Distro-AS-4.2.3/workspace/stack-metro/thirdparty/jbossws-jboss42-resources.zip
| -rw-rw-r-- 1 tdiesler tdiesler 4767 Nov 20 18:32 Metro-Integration-AS-4.2.2/workspace/stack-metro/thirdparty/jbossws-jboss42-resources.zip
| -rw-rw-r-- 1 tdiesler tdiesler 4767 Nov 20 18:32 Metro-Integration-AS-4.2.3/workspace/stack-metro/thirdparty/jbossws-jboss42-resources.zip
| -rw-rw-r-- 1 tdiesler tdiesler 4767 Nov 20 18:32 Native-Core-AS-4.2.1/workspace/stack-native/thirdparty/jbossws-jboss42-resources.zip
| -rw-rw-r-- 1 tdiesler tdiesler 4767 Nov 20 18:32 Native-Core-AS-4.2.2/workspace/stack-native/thirdparty/jbossws-jboss42-resources.zip
| -rw-rw-r-- 1 tdiesler tdiesler 4767 Nov 20 18:32 Native-Core-AS-4.2.3/workspace/stack-native/thirdparty/jbossws-jboss42-resources.zip
| -rw-rw-r-- 1 tdiesler tdiesler 4767 Nov 20 18:32 Native-Distro-AS-4.2.1/workspace/stack-native/thirdparty/jbossws-jboss42-resources.zip
| -rw-rw-r-- 1 tdiesler tdiesler 4767 Nov 20 18:32 Native-Distro-AS-4.2.2/workspace/stack-native/thirdparty/jbossws-jboss42-resources.zip
| -rw-rw-r-- 1 tdiesler tdiesler 4767 Nov 20 18:32 Native-Distro-AS-4.2.3/workspace/stack-native/thirdparty/jbossws-jboss42-resources.zip
| -rw-rw-r-- 1 tdiesler tdiesler 4767 Nov 20 18:32 Native-Integration-AS-4.2.1/workspace/stack-native/thirdparty/jbossws-jboss42-resources.zip
| -rw-rw-r-- 1 tdiesler tdiesler 4767 Nov 20 18:32 Native-Integration-AS-4.2.2/workspace/stack-native/thirdparty/jbossws-jboss42-resources.zip
| -rw-rw-r-- 1 tdiesler tdiesler 4767 Nov 20 18:32 Native-Integration-AS-4.2.3/workspace/stack-native/thirdparty/jbossws-jboss42-resources.zip
|
As you can see it uses a different version of jbossws-jboss42-resources.zip. Namely the one available in jbossws-jboss42/4.2.3.CR1
I reverted to jbossws-jboss42/4.2.1.GA for various reasons that are being discussed elsewhere.
The issue at hand is that
| <get src="${jboss.repository}/jboss/jbossws-jboss42/${jbossws-jboss42}/lib/jbossws-jboss42-resources.zip" dest="${thirdparty.dir}/jbossws-jboss42-resources.zip" usetimestamp="true" verbose="true"/>
|
uses the timestamp on the destination file and if newer does not replace the file.
We could of course usetimestamp="fasle", which would result in every thirdparty artifact being downloaded every time. Hence this would make the hudson runs realy slow.
I am trying a different approach, that would delete the thirdparty.dir whenever the version.properties changes
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4138059#4138059
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4138059
18 years
[Design the new POJO MicroContainer] - WARNING: Preparing release of MC betas
by adrian＠jboss.org
WARNING RELEASES IN PROGRESS
Over the next couple of days I'm going to be preparing and releasing
the next betas of the MC projects.
SCOTT - NOTE I'm releasing org.jboss.man properly
One time only, I'm going to do the metatype and managed projects
then I'll leave it up to Scott to move these to GA.
I'm doing it this time so we have a reference beta release for these new projects
and we are no longer using snapshots in the appserver where we don't need to.
LATEST VERSIONS
As part of this work, I'm going to be doing snapshots first where I upgrade dependencies
to the latest versions available in the Maven repository, so dependent builds based on
snapshots may not build correctly until I get around to them later today.
e.g. I'll be upgrading javassist to 3.7.1.GA from 3.6.0.GA in jboss-reflect shortly
(although this is an optional dependency of that project so it shouldn't cause
too many problems?)
BETA RELEASES
Once I have a full set of snapshots building correctly, I'll then move onto
the beta releases in the following order:
jboss-reflect
jboss-mdr
jboss-metatype/managed
microcontainer
classloader
deployers
RELIANCE
Ales, its upto you whether you do a beta release of reliance,
but I'll make sure the snapshot is up-to-date with the beta releases they depend upon.
Again, this is one-time only. Once reliance is referencing betas, it will be upto you to
move this forward as you change the dependencies.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4138053#4138053
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4138053
18 years
[Design the new POJO MicroContainer] - Re: beanfactory extensions
by alesj
"adrian(a)jboss.org" wrote :
| It should just be a case of adding an attribute to beanfactory to override the hardwired GenericBeanFactory implementation class?
Do we leave it completely to the user if the new factory class doesn't have the right 'shape' to get all those things injected:
| /** The configurator */
| protected KernelConfigurator configurator;
|
| /** The bean class name */
| protected String bean;
|
| /** The access mode */
| protected BeanAccessMode accessMode;
|
| /** The classloader */
| protected ClassLoaderMetaData classLoader;
|
| /** The constructor metadata */
| protected ConstructorMetaData constructor;
|
| /** The properties Map<propertyName, ValueMetaData> */
| protected Map<String, ValueMetaData> properties;
|
| /** The create lifecycle method */
| protected LifecycleMetaData create;
|
| /** The start lifecycle method */
| protected LifecycleMetaData start;
|
I don't see what much we could do.
Perhaps GenericBeanFactoryMetaData::getBeans could return some extended AbstractBeanMetaData where we would override describeVisit method to check if the bean has appropriate hooks to do instantiation with KernelConfigurator parameter, configuration with all those properties, ...
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4138043#4138043
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4138043
18 years
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: 2.0 source code preview
by kawasaki
I have not looked at Camel source code so cant say at which level of abstraction is the actual integration, ideally of course it would be at JMS API level.
Regarding the CEP/ESP concepts, in case you have not had a chance to look at this technology so Ill try to illustrate:
Lets say we have two streams of real-time messages called A (first stream) and B (second stream). This maps to JMS concepts such as queue or topic aka destination.
No lets say we have 2 business requirements:
1) If message M1 comes in stream A, and message M2 does appear on stream B after maximum 5 seconds, do some action.
2) Provide sliding window facilities that covers messages in last 5 seconds for stream A and B that satisfy condition that field F1 from message in stream A is equal to F2 of messages in stream B.
In technical terms administrator would define these declarative (no compile/restart required) requirements as follows:
1) EVERY m1 FROM a FOLLOWED BY m2 FROM b TIME_WINDOW(5)
2)SELECT a.*, b.* FROM a, a WHERE a.f1=b.f2 and TIME_WINDOW(5)
Basically reversed relational database, SQL like API for managing and correlating messages.
Does JBoss middleware has need for such thing? Any opinions appreciated.
Thanks
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4138040#4138040
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4138040
18 years