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
14 years, 7 months
JBM Examples moving to AS 5
by Howard Gao
Hi JBoss team,
I'm working to add JBoss Messaging 1.4 examples to AS 5 SVN repo. The
location I put those examples is
messaging/src/etc/examples
and the examples will be built into AS 5 installation package, the
location will be :
$JBOSS_HOME/docs/examples/jms/examples
I'm asking two questions,
1. are those above locations OK ?
2. I'm working on the AS 5 trunk
(https://svn.jboss.org/repos/jbossas/trunk), is that also OK that those
changes go to the trunk?
Thanks.
Howard
14 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.
14 years, 9 months
Re: [jboss-dev] Include Web Beans RI in next JBoss 5 release
by Pete Muir
Thanks for the pointers; I went with the option Carlo and Scott
suggested.
Web Beans Alpha2 is now in trunk and Branch_5_x, so if you want to
check it out, I suggest you get the Web Beans ALPHA2 distribution from
seamframework.org and try out one of the examples.
On 30 Jan 2009, at 17:56, Scott Stark wrote:
> Pete Muir wrote:
>> I'm now looking at adding the deployer to Branch_5_x and trunk. I
>> need some guidance on how to do this.
>>
>> Options:
>>
>> 1) store the *-jboss-beans.xml in the webbeans-jbossas-int project,
>> assemble the deployer there, and attach to the webbeans-jbossas-
>> int.jar as a zip. In this case, the only modification to jbossas is
>> to add a dependency on this zip, and then add the unzip to the
>> build somewhere (where?)
> Where does webbeans-jbossas-int live now? I see a webbeans-ri-int
> under svn.jboss.org/repos/jbossas/projects/.
Yes, it's one of the modules of this project
> It sounds like webbeans-jbossas-int would be the place to have the
> deployer so its available to other projects/assemblies. It would be
> unziped into the jbossas distribution by its build assembly script
> (jbossas/build/build-distr.xml currently).
I added a subproject to create the deployer to svn.jboss.org/repos/
jbossas/projects/webbeans-ri-int.
>
>>
>> 2) store the *-jboss-beans.xml in the jbossas project (where?) and
>> assemble the deployer there
>>
>> 3) something else?
>>
>> Thanks,
>>
>> Pete
>>
>
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
14 years, 10 months
Re: [jboss-dev] Include Web Beans RI in next JBoss 5 release
by Pete Muir
I'm now looking at adding the deployer to Branch_5_x and trunk. I need
some guidance on how to do this.
Options:
1) store the *-jboss-beans.xml in the webbeans-jbossas-int project,
assemble the deployer there, and attach to the webbeans-jbossas-
int.jar as a zip. In this case, the only modification to jbossas is to
add a dependency on this zip, and then add the unzip to the build
somewhere (where?)
2) store the *-jboss-beans.xml in the jbossas project (where?) and
assemble the deployer there
3) something else?
Thanks,
Pete
On 14 Jan 2009, at 22:03, Dimitris Andreadis wrote:
> Shouldn't we leave the webbeans integration for 5.1? (Branch_5_x)
>
> 5.0.1 is a bug fixing release...
>
> Scott Stark wrote:
>> In going through the integration of the current webeans
>> 1.0.0.Alpha1 RI with the jbossas-5.0.0.GA release, the number guess
>> example fails to deploy on startup with:
>> Caused by: java.lang.NullPointerException
>> at
>> org
>> .jboss
>> .webbeans
>> .integration
>> .jbossas
>> .ejb3.EjbDiscoveryEnvironment.lookup(EjbDiscoveryEnvironment.java:
>> 123) at
>> org
>> .jboss
>> .webbeans
>> .integration
>> .jbossas
>> .ejb3.EjbDiscoveryEnvironment.<init>(EjbDiscoveryEnvironment.java:
>> 41) at
>> org
>> .jboss
>> .webbeans
>> .integration
>> .jbossas.WebBeanDiscoveryImpl.<init>(WebBeanDiscoveryImpl.java:
>> 25) ... 65 more
>> 10:30:59,909 INFO [WebBeansBootstrap] Starting Web Beans RI
>> 1.0.0.ALPHA1
>> 10:30:59,909 ERROR [[/webbeans-numberguess]] Exception sending
>> context initialized event to listener instance of class
>> org.jboss.webbeans.servlet.WebBeansListener
>> So I guess we need to focus on web beans integration tests as well.
>> _______________________________________________
>> 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
14 years, 10 months
Branch_5_0 freeze - when?
by Dimitris Andreadis
We are targeting the 5.0.1.GA for the end of the week, so a code freeze by tomorrow (27th)
or Wednesday at most (28th) is due.
If you have pending updates/changes now is the time to rush. The most difficult bit at this
point is the update to VFS libs along with all the cascading MC/deployer dependencies.
https://jira.jboss.org/jira/browse/JBAS
Thanks
/Dimitris
14 years, 10 months
EJB3 Release Schedule
by Andrew Lee Rubinger
We're pleased to announce that JBoss EJB3 is making the final push
towards 1.0.0-GA, and will soon be implementing a timeboxed release
schedule.
====================
|| Current Status ||
====================
Released Friday morning, 1.0.0-Beta12 of the EJB3/AS Integration Module
(org.jboss.ejb3:jboss-ejb3-as-int:1.0.0-Beta12) is now in AS:
* trunk
* Branch_5_x
* Branch_5_0
This is likely the last of the 1.0.0-BetaX series, and pending the
completion of all Hudson runs to expected results, will be re-cut as
1.0.0-CR1 this weekend.
Criteria for EJB3 1.0.0-CR1 is:
* No regression in TCK
* No regression in AS TestSuite
* Passes EJB3 Integration TestSuite 100% (excluding transient failures
and identified known issues)
After a standard 1-week(ish) incubation period, CR1 (assuming all is
well) will be promoted to 1.0.0-GA sometime Thursday/Friday, 23 January,
and will be integrated will all active branches of AS. This targets AS
5.0.1 to include EJB3 1.0.0-GA.
========================
|| Timeboxed Releases ||
========================
After the 1.0.0-GA Release of the EJB3 Projects, we will continue to
push releases both to the community and into AS active branches at a
resolution of twice a month[1]. The EJB3 Team has not yet agreed upon a
formal schedule (ie. every 1st and 3rd Monday will lead to occasional
gaps in cases where a month has 5 Mondays). After we've set this, we'll
reply back to this list with a commitment upon which the community and
dependent projects (ie. AS, WebBeans) may rely.
Additionally, we'll be using a true timebox methodology[2]; bug fixes
and feature requests that are not completed in time for release will be
bumped to the next development cycle. We will make every effort to not
delay a release in order to get further improvements incorporated,
barring exceptional circumstances.
=================
|| EJB3 Plugin ||
=================
In addition to updating AS, we'll be re-introducing the concept of the
"EJB3 Plugin"[3].
The EJB3 Plugin is currently implemented as an executable JAR which will
patch an existing AS installation with the latest EJB3 binaries (and
dependent projects[4]). Usage looks like:
shell $> java -jar jboss-ejb3-plugin.jar $JBOSS_HOME
We will keep each release of the Plugin backwards-compatible with the
latest release of AS. Therefore the first release will work against AS
5.0.0.GA, and after 5.0.1.GA is released the Plugin will target 5.0.1.GA
*only*. This is to:
* Give users the latest and greatest
* Limit the scope of development resources needed to continually deliver
(by supporting only one target AS version).
* Encourage community members to embrace the "release early, release
often" intent of .org
===================================
||Implications for the Community ||
===================================
Because we're moving to a reliable, repeatable release schedule,
community members interested in helping the development process can be
assured that their contributions will be made available as a binary
within 2 weeks. Your efforts might take the form of:
* Failing use cases / bug reports
* Unit / Integration Tests
* Documentation
* Enhancements / patches
We encourage you to get involved.
S,
ALR
References:
[1] I avoid the term "bimonthly": http://en.wiktionary.org/wiki/bimonthly
[2] http://en.wikipedia.org/wiki/Time_boxing
[3] http://jboss.org/community/docs/DOC-9564, once released, will be
updated to show end-user usage separately from concepts interesting to
developers
[4] Sometimes we must also update projects technically outside EJB3
scope, ie. jboss-metadata, jboss-jpa-deployers
--
Andrew Lee Rubinger
Sr. Software Engineer
JBoss, a division of Red Hat, Inc.
http://exitcondition.alrubinger.com
14 years, 10 months
CachePolicyVFSCache shutdown error
by Scott Stark
When shutting down the jbossas trunk I'm seeing the following error:
09:13:15,306 WARN [StartStopLifecycleAction] Error during stop for
WSSubscriptionManager
java.lang.IllegalArgumentException: Cache needs to be started first.
at
org.jboss.virtual.plugins.cache.CachePolicyVFSCache.check(CachePolicyVFSCache.java:78)
at
org.jboss.virtual.plugins.cache.AbstractVFSCache.getFile(AbstractVFSCache.java:101)
at
org.jboss.virtual.protocol.AbstractVFSHandler.openConnection(AbstractVFSHandler.java:72)
at java.net.URL.openConnection(URL.java:943)
at java.net.URL.openStream(URL.java:1007)
at
com.sun.naming.internal.VersionHelper12$InputStreamEnumeration$1.run(VersionHelper12.java:195)
at java.security.AccessController.doPrivileged(Native Method)
at
com.sun.naming.internal.VersionHelper12$InputStreamEnumeration.getNextElement(VersionHelper12.java:190)
at
com.sun.naming.internal.VersionHelper12$InputStreamEnumeration.hasMore(VersionHelper12.java:210)
at
com.sun.naming.internal.ResourceManager.getApplicationResources(ResourceManager.java:470)
at
com.sun.naming.internal.ResourceManager.getInitialEnvironment(ResourceManager.java:159)
at javax.naming.InitialContext.init(InitialContext.java:219)
at javax.naming.InitialContext.<init>(InitialContext.java:175)
at
org.jboss.ws.extensions.eventing.mgmt.SubscriptionManager.stop(SubscriptionManager.java:183)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
at
org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
at
org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
at
org.jboss.kernel.plugins.dependency.KernelControllerContextAction$JoinpointDispatchWrapper.execute(KernelControllerContextAction.java:241)
at
org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47)
at
org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:109)
at
org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:70)
at
org.jboss.kernel.plugins.dependency.LifecycleAction.uninstallActionInternal(LifecycleAction.java:249)
at
org.jboss.kernel.plugins.dependency.InstallsAwareAction.uninstallAction(InstallsAwareAction.java:157)
at
org.jboss.kernel.plugins.dependency.InstallsAwareAction.uninstallAction(InstallsAwareAction.java:42)
at
org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleUninstallAction(SimpleControllerContextAction.java:79)
at
org.jboss.dependency.plugins.action.AccessControllerContextAction.uninstall(AccessControllerContextAction.java:131)
at
org.jboss.dependency.plugins.AbstractControllerContextActions.uninstall(AbstractControllerContextActions.java:58)
at
org.jboss.dependency.plugins.AbstractControllerContext.uninstall(AbstractControllerContext.java:354)
at
org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:1631)
at
org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1242)
at
org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1146)
at
org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:655)
at
org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:568)
at
org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.undeploy(BeanMetaDataDeployer.java:153)
at
org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.undeploy(BeanMetaDataDeployer.java:51)
at
org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalUndeploy(AbstractSimpleRealDeployer.java:69)
at
org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.undeploy(AbstractRealDeployer.java:112)
at
org.jboss.deployers.plugins.deployers.DeployerWrapper.undeploy(DeployerWrapper.java:196)
at
org.jboss.deployers.plugins.deployers.DeployersImpl.doUndeploy(DeployersImpl.java:1469)
at
org.jboss.deployers.plugins.deployers.DeployersImpl.doUninstallParentLast(DeployersImpl.java:1376)
at
org.jboss.deployers.plugins.deployers.DeployersImpl.doUninstallParentLast(DeployersImpl.java:1369)
at
org.jboss.deployers.plugins.deployers.DeployersImpl.uninstall(DeployersImpl.java:1331)
at
org.jboss.dependency.plugins.AbstractControllerContext.uninstall(AbstractControllerContext.java:354)
at
org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:1631)
at
org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1242)
at
org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:827)
at
org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
at
org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:694)
at
org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:545)
at
org.jboss.system.server.profileservice.repository.ProfileDeployAction.uninstall(ProfileDeployAction.java:89)
at
org.jboss.system.server.profileservice.repository.AbstractProfileLifeCycleAction.uninstall(AbstractProfileLifeCycleAction.java:73)
at
org.jboss.system.server.profileservice.repository.AbstractProfileService.uninstall(AbstractProfileService.java:309)
at
org.jboss.dependency.plugins.AbstractControllerContext.uninstall(AbstractControllerContext.java:354)
at
org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:1631)
at
org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1242)
at
org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1146)
at
org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1201)
at
org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:827)
at
org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
at
org.jboss.system.server.profileservice.repository.AbstractProfileService.releaseProfile(AbstractProfileService.java:336)
at
org.jboss.system.server.profileservice.ProfileServiceBootstrap.shutdown(ProfileServiceBootstrap.java:281)
at
org.jboss.bootstrap.AbstractServerImpl.shutdownServer(AbstractServerImpl.java:504)
at
org.jboss.bootstrap.AbstractServerImpl$ShutdownHook.run(AbstractServerImpl.java:832)
14 years, 10 months
