VFS3 (in AS trunk) - Non .jar file handling
by Jaikiran Pai
I see a new behaviour with VFS3 in JBoss AS. Earlier in AS-5/6 (with
VFS2) and AS-4 (without any VFS), to try out some quick fixes, i used to
rename existing jar files to end with .bak name and replace them with
the new patched jar file. So for example, if i had a fix in
jboss-ejb3-core.jar, i would:
1) Rename the JBOSS_HOME/common/lib/jboss-ejb3-core.jar to
JBOSS_HOME/common/lib/jboss-ejb3-core.jar.orig.bak
2) Place a patched jboss-ejb3-core.jar in JBOSS_HOME/common/lib
3) Restart the server
The server would then pickup the new patched jar file and ignore the
.bak file. After testing the fix, i would then revert back to the
original jar file by renaming it back to its original name.
However, with the recent upgrade to VFS3 in AS trunk, i notice that even
the .bak is used for classloading (following is the output from
-verbose:class JVM argument):
[Loaded org.jboss.ejb3.EJBContainer from
file:/NotBackedUp/jpai/business/jboss/wc/jbossas/trunk/build/target/jboss-6.0.0-SNAPSHOT/common/lib/jboss-ejb3-core.jar.orig.bak/]
Looks like VFS3 picks up this non .jar suffix file for classloading. Is
this expected? Shouldn't it be looking for only .jar files (atleast in
this context)?
regards,
-Jaikiran
10 years, 10 months
Porting SVN Projects to Git
by Andrew Lee Rubinger
Today I look a relatively simple project and migrated it from SVN to
Git. There's a bunch of resources scattered about involving the "best"
way to do this, but thought I'd share my experience as it appears to
have been a success. If anyone's got a better process I'm interested, too.
Note: I'm on Fedora13, so some commands here are gonna be env-specific.
# Obtain dependencies which run or are run from the svn2git Ruby script
$> sudo yum -y install git-core git-svn ruby rubygems
(Original instructions used apt-get, so I assume Debianey/Ubuntooey
distros support this command too)
# Install the svn2git gem (script)
$> sudo gem install svn2git --source http://gemcutter.org
# Make a new directory to contain your new local Git repo and switch into it
$> mkdir jboss-ejb3-async; cd jboss-ejb3-async
# (Optional) Create a mapping file from SVN usernames to Git Authors
$> svn log | grep -E "r[0-9]+ \| [a-z]+ \|" | awk '{print $3}' | sort |
uniq # Prints out all authors for the current SVN working copy
File format should be:
SVNUsername = Full Name <email.address.org>
ALRubinger = Andrew Lee Rubinger <alr(a)jboss.org>
# Use svn2git to extract out the SVN commit information, passing along
parameters to note trunk, tags, branches locations
$> svn2git https://svn.jboss.org/repos/jbossas/ --trunk
projects/ejb3/components/async/trunk --tags
projects/ejb3/components/async/tags --nobranches --authors ../authors.txt
(More info on the switches at: http://github.com/nirvdrum/svn2git)
# Create a remote repo somewhere (I did GitHub and used the web console
for that)
# Add a remote "origin" to the local repo so we can push to it
$> git remote add origin git@github.com:ALRubinger/jboss-ejb3-async.git
# Push all contents including the tags to the origin at branch master
$> git push --tags origin master
S,
ALR
11 years, 2 months
JBossAS 6.0.0.M4 released
by Rajesh Rajasekaran
JBoss Application Server 6.0 Milestone 4 has been released and is
available for download.
http://www.jboss.org/jbossas/downloads.html
The release is also available in the maven repository.
JBoss AS 6.0.0.M4 is the fourth milestone release of the community
driven AS 6 series. Building on the first , second, and third
milestone releases, it includes support for additional key technologies
that are part of the EE6 specification.
Two major EJB 3.1 features included in this release are:
* Asynchronous EJB invocation - An approach that allows clients to
invoke an operation and check the response later.
* Advanced Timers - The ability to have calendar based timers
trigger EJB methods. See the following overview for more information.
Other major additions include:
* JBossWS-CXF - A new web services implementation that is built on
top of the Apache CXF web services stack. This change offers existing
JBossWS users better performance and more WS-* features.
* Resteasy 2.0 - A major update that includes full CDI and EJB
integration. Resteasy specific classes are no longer needed in web.xml.
* XA Recovery - XA sources are now automatically registered for
recovery. See jboss-ds_6_0.dtd for details.
* Many bug fixes and small enhancements as listed in the full notes
below.
http://community.jboss.org/wiki/AS600M4ReleaseNotes
Thanks
Rajesh
11 years, 2 months
1' hornetq delay on first boot
by Dimitris Andreadis
On a 4y old WinXP laptop, hornetq seems to be adding a 1 minute delay on the first boot,
while creating the server/xxx/data/hornetq/journal/* files
2nd boot comes without that delay. Can we avoid this?
14:03:27,624 INFO [AbstractServer] Starting: JBossAS [6.0.0.SNAPSHOT "Neo"]
14:03:29,702 INFO [ServerInfo] Java version: 1.6.0_16,Sun Microsystems Inc.
14:03:29,702 INFO [ServerInfo] Java Runtime: Java(TM) SE Runtime Environment (b
uild 1.6.0_16-b01)
14:03:29,702 INFO [ServerInfo] Java VM: Java HotSpot(TM) Server VM 14.2-b01,Sun
Microsystems Inc.
14:03:29,702 INFO [ServerInfo] OS-System: Windows XP 5.1,x86
14:03:29,702 INFO [ServerInfo] VM arguments: -Dprogram.name=run.bat -Xms128M -X
mx512M -XX:MaxPermSize=256M -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dg
c.server.gcInterval=3600000 -Dorg.jboss.resolver.warning=true -Djava.endorsed.di
rs=X:\svn\jboss-trunk\build\target\jboss-6.0.0-SNAPSHOT\lib\endorsed
14:03:29,780 INFO [JMXKernel] Legacy JMX core initialized
14:03:37,811 INFO [AbstractServerConfig] JBoss Web Services - Stack CXF Server
3.3.1.SP1
14:03:38,405 INFO [JSFImplManagementDeployer] Initialized 2 JSF configurations:
[Mojarra-1.2, Mojarra-2.0]
14:03:42,749 WARNING [FileConfigurationParser] AIO wasn't located on this platfo
rm, it will fall back to using pure Java NIO. If your platform is Linux, install
LibAIO to enable the AIO journal
14:03:47,483 WARNING [FileConfigurationParser] AIO wasn't located on this platfo
rm, it will fall back to using pure Java NIO. If your platform is Linux, install
LibAIO to enable the AIO journal
14:03:47,671 INFO [JMXConnector] starting JMXConnector on host 127.0.0.1:1090
14:03:48,202 INFO [MailService] Mail Service bound to java:/Mail
14:03:49,280 INFO [HornetQServerImpl] live server is starting..
14:03:49,358 INFO [JournalStorageManager] Using NIO Journal
14:03:49,374 WARNING [HornetQServerImpl] Security risk! It has been detected tha
t the cluster admin user and password have not been changed from the installatio
n default. Please see the HornetQ user guide, cluster chapter, for instructions
on how to do this.
<-- HERE -->
14:04:52,077 INFO [NettyAcceptor] Started Netty Acceptor version 3.2.0.Final-r2
292 127.0.0.1:5455 for CORE protocol
14:04:52,092 INFO [NettyAcceptor] Started Netty Acceptor version 3.2.0.Final-r2
292 127.0.0.1:5445 for CORE protocol
14:04:52,092 INFO [HornetQServerImpl] HornetQ Server version 2.1.1.Final (Strip
ey, 119) started
[snip]
14:08:24,827 INFO [org.jboss.bootstrap.impl.base.server.AbstractServer] JBossAS
[6.0.0.SNAPSHOT "Neo"] Started in 1m:30s:656ms
11 years, 3 months
M4 branched, AS trunk open
by Brian Stansberry
FYI, last night Jason created a branch for the M4 release.[1] Similar to
the M2 release, the final QE tasks for the release will be done on that
branch, with the expectation that the final M4 tag will be essentially
the same as the root of the branch.
The M4 release will probably come out early next week.
AS trunk is now open for normal development work toward AS 6.0 final.
[1] https://svn.jboss.org/repos/jbossas/branches/6.0.0.20100721-M4
--
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat
11 years, 3 months
new profiles for AS6 + mvn artifact classloading
by Bill Burke
For AS6 I was wondering if we could do a couple of things:
1. Ditch the old profiles. Remove 'all', 'default', and 'minimal'.
Replace with 'production' and 'development'.
'production' would be tuned for runtime performance, security, and
anything else we can think of. It would also be the 'all' profile
containing clustering jars, etc. 'development' would be tuned for boot
time performance, i.e. zero-persistence HornetQ, removal of unneeded
development components (like clustering) and anything else we can think
of. It might also be interesting to create a 'legacy' profile which
contains things like EJB2, JAX-RPC, the ancient scheduler, and anything
else we can think of. These legacy components would be removed from
'development' and maybe 'production'. I don't know, just some ideas.
Maybe 'production' also has a boot-bean that checks to see if people
have changed the password for the management console, hornetq, etc...
2. I really want to push the 'booting from a local maven repository'
idea that has been floated around by me and many others. Of course, I
like what I did as it is a minimal code change, minimal processing, and
a very simple interface to <classloader>, but I don't care what code is
used. I think there are a few advantages to this approach:
- Our main distribution becomes smaller. How much? Not sure, but I'm
guessing at least 25% smaller.
- Shipping a profile becomes much smaller and can be just a bunch of
text files and directories. Such shipped profiles could have a simple
pom.xml that downloaded all the dependend libraries into the user's
local maven repository.
Now, I'm not suggesting we just do these things outright. We could blog
about it, post on forums, ask customers, etc. Get some input before we
make the changes. But, IMO, the above are simple changes that require
only a bit of monotonous, brain-dead work.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
11 years, 3 months
m4 is when?
by Bill Burke
I want to do another RESTEasy release (2.0.GA) before M4 is released so
M4 is up-to-date... ETA on M4?
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
11 years, 3 months
EJB 3.1 @Asynchronous Support in M4
by Andrew Lee Rubinger
Update on the @Asynchronous support for AS 6.0.0.M4:
Last week we made a design change in the asynchronous component of EJB3
to move to client-side interceptors instead of server-side. The reason was:
1) For the server to push the result to the client, we'd need
bidirectional communication (ie. R2 bisocket impl) of some type, which
is bound to not play nicely with firewalls
2) If the client were to poll the server for results, we'd be making a
result store (which is a memory leak by design unless we implemented
some serialization or expiry policy, added complexity).
The unit tests for the client-side async model have been working fine,
as have the integration tests in the AS testsuite.
I have, however, made an Embedded test to reliably ensure that
@Asynchronous invocations do indeed occur in a separate Thread. What
I've discovered is that for @Remote business interfaces, all is firing
as expected. In @Local business interfaces however, this is not the case.
I've discovered the root of this is because EJB local proxies do not
have client-side interceptors at all. I'm halfway through patching the
impl to support this notion.
For M4 launch we can:
1) Continue along and provide @Asynchronous support for remote business
interfaces only
2) Get the proper fixes into the EJB3 proxy mechanism to support
client-side interception
Aside from this issue, EJB3 team is go for M4 (Jaikiran's components
were integrated today).
I'm on #jboss-dev tomorrow to discuss.
S,
ALR
11 years, 3 months
Error installing to Start
by sandeep kotha
Hi all
Im getting the below error any help to this issue will be a great help. Im
using mysql with hibernate 3.
23:15:15,390 INFO [LogNotificationListener] Adding notification listener
for logging mbean "jboss.system:service=Logging,type=Log4jService" to server
org.jboss.mx.server.MBeanServerImpl@154ea79[ defaultDomain='jboss' ]
23:15:28,109 INFO [Ejb3DependenciesDeployer] Encountered deployment
AbstractVFSDeploymentContext@28562961{vfsfile:/F:/
jboss-5.1.0.GA/server/default/deploy/profileservice-secured.jar/}
23:15:28,109 INFO [Ejb3DependenciesDeployer] Encountered deployment
AbstractVFSDeploymentContext@28562961{vfsfile:/F:/
jboss-5.1.0.GA/server/default/deploy/profileservice-secured.jar/}
23:15:28,109 INFO [Ejb3DependenciesDeployer] Encountered deployment
AbstractVFSDeploymentContext@28562961{vfsfile:/F:/
jboss-5.1.0.GA/server/default/deploy/profileservice-secured.jar/}
23:15:28,109 INFO [Ejb3DependenciesDeployer] Encountered deployment
AbstractVFSDeploymentContext@28562961{vfsfile:/F:/
jboss-5.1.0.GA/server/default/deploy/profileservice-secured.jar/}
23:15:30,218 ERROR [AbstractKernelController] Error installing to Start:
name=jboss.remoting:protocol=rmi,service=JMXConnectorServer state=Create
mode=Manual requiredState=Installed
*java.rmi.server.ExportException*: Port already in use: 1090; nested
exception is:
*java.net.BindException*: Address already in use: JVM_Bind
at sun.rmi.transport.tcp.TCPTransport.listen(Unknown Source)
at sun.rmi.transport.tcp.TCPTransport.exportObject(Unknown Source)
at sun.rmi.transport.tcp.TCPEndpoint.exportObject(Unknown Source)
at sun.rmi.transport.LiveRef.exportObject(Unknown Source)
at sun.rmi.server.UnicastServerRef.exportObject(Unknown Source)
at sun.rmi.registry.RegistryImpl.setup(Unknown Source)
at sun.rmi.registry.RegistryImpl.<init>(Unknown Source)
at java.rmi.registry.LocateRegistry.createRegistry(Unknown Source)
at org.jboss.mx.remoting.service.JMXConnectorServerService.start(*
JMXConnectorServerService.java:117*)
at sun.reflect.NativeMethodAccessorImpl.invoke0(*Native Method*)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(*
ReflectedDispatcher.java:157*)
at org.jboss.mx.server.Invocation.dispatch(*Invocation.java:96*)
at org.jboss.mx.server.Invocation.invoke(*Invocation.java:88*)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(*
AbstractMBeanInvoker.java:264*)
at org.jboss.mx.server.MBeanServerImpl.invoke(*
MBeanServerImpl.java:668*)
at org.jboss.system.microcontainer.ServiceProxy.invoke(*
ServiceProxy.java:206*)
at $Proxy38.start(Unknown Source)
at
org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(*
StartStopLifecycleAction.java:42*)
at
org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(*
StartStopLifecycleAction.java:37*)
at
org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(
*SimpleControllerContextAction.java:62*)
at
org.jboss.dependency.plugins.action.AccessControllerContextAction.install(*
AccessControllerContextAction.java:71*)
at
org.jboss.dependency.plugins.AbstractControllerContextActions.install(*
AbstractControllerContextActions.java:51*)
at org.jboss.dependency.plugins.AbstractControllerContext.install(*
AbstractControllerContext.java:348*)
at org.jboss.system.microcontainer.ServiceControllerContext.install(*
ServiceControllerContext.java:286*)
at org.jboss.dependency.plugins.AbstractController.install(*
AbstractController.java:1631*)
at org.jboss.dependency.plugins.AbstractController.incrementState(*
AbstractController.java:934*)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(*
AbstractController.java:1082*)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(*
AbstractController.java:984*)
at org.jboss.dependency.plugins.AbstractController.change(*
AbstractController.java:822*)
at org.jboss.dependency.plugins.AbstractController.change(*
AbstractController.java:553*)
at org.jboss.system.ServiceController.doChange(*
ServiceController.java:688*)
at org.jboss.system.ServiceController.start(*
ServiceController.java:460*)
at org.jboss.system.deployers.ServiceDeployer.start(*
ServiceDeployer.java:163*)
at org.jboss.system.deployers.ServiceDeployer.deploy(*
ServiceDeployer.java:99*)
at org.jboss.system.deployers.ServiceDeployer.deploy(*
ServiceDeployer.java:46*)
at
org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(
*AbstractSimpleRealDeployer.java:62*)
at
org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(*
AbstractRealDeployer.java:50*)
at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(*
DeployerWrapper.java:171*)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(*
DeployersImpl.java:1439*)
at
org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(*
DeployersImpl.java:1157*)
at
org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(*
DeployersImpl.java:1178*)
at org.jboss.deployers.plugins.deployers.DeployersImpl.install(*
DeployersImpl.java:1098*)
at org.jboss.dependency.plugins.AbstractControllerContext.install(*
AbstractControllerContext.java:348*)
at org.jboss.dependency.plugins.AbstractController.install(*
AbstractController.java:1631*)
at org.jboss.dependency.plugins.AbstractController.incrementState(*
AbstractController.java:934*)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(*
AbstractController.java:1082*)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(*
AbstractController.java:984*)
at org.jboss.dependency.plugins.AbstractController.change(*
AbstractController.java:822*)
at org.jboss.dependency.plugins.AbstractController.change(*
AbstractController.java:553*)
at org.jboss.deployers.plugins.deployers.DeployersImpl.process(*
DeployersImpl.java:781*)
at org.jboss.deployers.plugins.main.MainDeployerImpl.process(*
MainDeployerImpl.java:702*)
at
org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(
*MainDeployerAdapter.java:117*)
at
org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(
*ProfileDeployAction.java:70*)
at
org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(
*AbstractProfileAction.java:53*)
at
org.jboss.system.server.profileservice.repository.AbstractProfileService.install(
*AbstractProfileService.java:361*)
at org.jboss.dependency.plugins.AbstractControllerContext.install(*
AbstractControllerContext.java:348*)
at org.jboss.dependency.plugins.AbstractController.install(*
AbstractController.java:1631*)
at org.jboss.dependency.plugins.AbstractController.incrementState(*
AbstractController.java:934*)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(*
AbstractController.java:1082*)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(*
AbstractController.java:984*)
at org.jboss.dependency.plugins.AbstractController.change(*
AbstractController.java:822*)
at org.jboss.dependency.plugins.AbstractController.change(*
AbstractController.java:553*)
at
org.jboss.system.server.profileservice.repository.AbstractProfileService.activateProfile(
*AbstractProfileService.java:306*)
at
org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(*
ProfileServiceBootstrap.java:271*)
at org.jboss.bootstrap.AbstractServerImpl.start(*
AbstractServerImpl.java:461*)
at org.jboss.Main.boot(*Main.java:221*)
at org.jboss.Main$1.run(*Main.java:556*)
at java.lang.Thread.run(Unknown Source)
Caused by: *java.net.BindException*: Address already in use: JVM_Bind
at java.net.PlainSocketImpl.socketBind(*Native Method*)
at java.net.PlainSocketImpl.bind(Unknown Source)
at java.net.ServerSocket.bind(Unknown Source)
at java.net.ServerSocket.<init>(Unknown Source)
at org.jboss.net.sockets.DefaultSocketFactory.createServerSocket(*
DefaultSocketFactory.java:124*)
at org.jboss.net.sockets.DefaultSocketFactory.createServerSocket(*
DefaultSocketFactory.java:99*)
at sun.rmi.transport.tcp.TCPEndpoint.newServerSocket(Unknown Source)
... 71 more
23:15:30,234 ERROR [AbstractKernelController] Error installing to Real:
name=vfsfile:/F:/jboss-5.1.0.GA/server/default/deploy/jmx-remoting.sar/
state=PreReal<http://jboss-5.1.0.GA/server/default/deploy/jmx-remoting.sar/state=PreReal>mode=Manual
requiredState=Real
*org.jboss.deployers.spi.DeploymentException*: Error deploying:
jboss.remoting:service=JMXConnectorServer,protocol=rmi
at
org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(*
DeploymentException.java:49*)
at org.jboss.system.deployers.ServiceDeployer.deploy(*
ServiceDeployer.java:118*)
at org.jboss.system.deployers.ServiceDeployer.deploy(*
ServiceDeployer.java:46*)
at
org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(
*AbstractSimpleRealDeployer.java:62*)
at
org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(*
AbstractRealDeployer.java:50*)
at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(*
DeployerWrapper.java:171*)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(*
DeployersImpl.java:1439*)
at
org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(*
DeployersImpl.java:1157*)
at
org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(*
DeployersImpl.java:1178*)
at org.jboss.deployers.plugins.deployers.DeployersImpl.install(*
DeployersImpl.java:1098*)
at org.jboss.dependency.plugins.AbstractControllerContext.install(*
AbstractControllerContext.java:348*)
at org.jboss.dependency.plugins.AbstractController.install(*
AbstractController.java:1631*)
at org.jboss.dependency.plugins.AbstractController.incrementState(*
AbstractController.java:934*)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(*
AbstractController.java:1082*)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(*
AbstractController.java:984*)
at org.jboss.dependency.plugins.AbstractController.change(*
AbstractController.java:822*)
at org.jboss.dependency.plugins.AbstractController.change(*
AbstractController.java:553*)
at org.jboss.deployers.plugins.deployers.DeployersImpl.process(*
DeployersImpl.java:781*)
at org.jboss.deployers.plugins.main.MainDeployerImpl.process(*
MainDeployerImpl.java:702*)
at
org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(
*MainDeployerAdapter.java:117*)
at
org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(
*ProfileDeployAction.java:70*)
at
org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(
*AbstractProfileAction.java:53*)
at
org.jboss.system.server.profileservice.repository.AbstractProfileService.install(
*AbstractProfileService.java:361*)
at org.jboss.dependency.plugins.AbstractControllerContext.install(*
AbstractControllerContext.java:348*)
at org.jboss.dependency.plugins.AbstractController.install(*
AbstractController.java:1631*)
at org.jboss.dependency.plugins.AbstractController.incrementState(*
AbstractController.java:934*)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(*
AbstractController.java:1082*)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(*
AbstractController.java:984*)
at org.jboss.dependency.plugins.AbstractController.change(*
AbstractController.java:822*)
at org.jboss.dependency.plugins.AbstractController.change(*
AbstractController.java:553*)
at
org.jboss.system.server.profileservice.repository.AbstractProfileService.activateProfile(
*AbstractProfileService.java:306*)
at
org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(*
ProfileServiceBootstrap.java:271*)
at org.jboss.bootstrap.AbstractServerImpl.start(*
AbstractServerImpl.java:461*)
at org.jboss.Main.boot(*Main.java:221*)
at org.jboss.Main$1.run(*Main.java:556*)
at java.lang.Thread.run(Unknown Source)
Caused by: *java.rmi.server.ExportException*: Port already in use: 1090;
nested exception is:
*java.net.BindException*: Address already in use: JVM_Bind
at sun.rmi.transport.tcp.TCPTransport.listen(Unknown Source)
at sun.rmi.transport.tcp.TCPTransport.exportObject(Unknown Source)
at sun.rmi.transport.tcp.TCPEndpoint.exportObject(Unknown Source)
at sun.rmi.transport.LiveRef.exportObject(Unknown Source)
at sun.rmi.server.UnicastServerRef.exportObject(Unknown Source)
at sun.rmi.registry.RegistryImpl.setup(Unknown Source)
at sun.rmi.registry.RegistryImpl.<init>(Unknown Source)
at java.rmi.registry.LocateRegistry.createRegistry(Unknown Source)
at org.jboss.mx.remoting.service.JMXConnectorServerService.start(*
JMXConnectorServerService.java:117*)
at sun.reflect.NativeMethodAccessorImpl.invoke0(*Native Method*)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(*
ReflectedDispatcher.java:157*)
at org.jboss.mx.server.Invocation.dispatch(*Invocation.java:96*)
at org.jboss.mx.server.Invocation.invoke(*Invocation.java:88*)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(*
AbstractMBeanInvoker.java:264*)
at org.jboss.mx.server.MBeanServerImpl.invoke(*
MBeanServerImpl.java:668*)
at org.jboss.system.microcontainer.ServiceProxy.invoke(*
ServiceProxy.java:206*)
at $Proxy38.start(Unknown Source)
at
org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(*
StartStopLifecycleAction.java:42*)
at
org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(*
StartStopLifecycleAction.java:37*)
at
org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(
*SimpleControllerContextAction.java:62*)
at
org.jboss.dependency.plugins.action.AccessControllerContextAction.install(*
AccessControllerContextAction.java:71*)
at
org.jboss.dependency.plugins.AbstractControllerContextActions.install(*
AbstractControllerContextActions.java:51*)
at org.jboss.dependency.plugins.AbstractControllerContext.install(*
AbstractControllerContext.java:348*)
at org.jboss.system.microcontainer.ServiceControllerContext.install(*
ServiceControllerContext.java:286*)
at org.jboss.dependency.plugins.AbstractController.install(*
AbstractController.java:1631*)
at org.jboss.dependency.plugins.AbstractController.incrementState(*
AbstractController.java:934*)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(*
AbstractController.java:1082*)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(*
AbstractController.java:984*)
at org.jboss.dependency.plugins.AbstractController.change(*
AbstractController.java:822*)
at org.jboss.dependency.plugins.AbstractController.change(*
AbstractController.java:553*)
at org.jboss.system.ServiceController.doChange(*
ServiceController.java:688*)
at org.jboss.system.ServiceController.start(*
ServiceController.java:460*)
at org.jboss.system.deployers.ServiceDeployer.start(*
ServiceDeployer.java:163*)
at org.jboss.system.deployers.ServiceDeployer.deploy(*
ServiceDeployer.java:99*)
... 34 more
Caused by: *java.net.BindException*: Address already in use: JVM_Bind
at java.net.PlainSocketImpl.socketBind(*Native Method*)
at java.net.PlainSocketImpl.bind(Unknown Source)
at java.net.ServerSocket.bind(Unknown Source)
at java.net.ServerSocket.<init>(Unknown Source)
at org.jboss.net.sockets.DefaultSocketFactory.createServerSocket(*
DefaultSocketFactory.java:124*)
at org.jboss.net.sockets.DefaultSocketFactory.createServerSocket(*
DefaultSocketFactory.java:99*)
at sun.rmi.transport.tcp.TCPEndpoint.newServerSocket(Unknown Source)
... 71 more
23:15:30,359 INFO [MailService] Mail Service bound to java:/Mail
23:15:32,265 WARN [JBossASSecurityMetadataStore] WARNING! POTENTIAL
SECURITY RISK. It has been detected that the MessageSucker component which
sucks messages from one node to another has not had its password changed
from the installation default. Please see the JBoss Messaging user guide for
instructions on how to do this.
23:15:32,281 WARN [AnnotationCreator] No ClassLoader provided, using TCCL:
org.jboss.managed.api.annotation.ManagementComponent
11 years, 3 months
Do all the deployers scan the same service classes ?
by Sergey Beryozkin
Hi,
sorry if it is a wrong list for this question...
I was playing a bit with picket-link OpenId web applications the other day and I was copying the required libraries those web apps would need one by one.
I was seeing (expected) ClassNotFoundExceptions but the stack trace was coming from the RestEasy deployer.
I'm wondering, does every JBossAS deployer does scan the endpoint ? Or is there some shared deployer which scans an endpoints for all the annotations and creates some per-endpoint annotations pools, and then concrete deployers check the annotations pools only ?
thanks, Sergey
11 years, 3 months
