[JBoss JIRA] Created: (JBJMX-101) failed to redeploy MBean dependent web module
by Maxim Gordienko (JIRA)
failed to redeploy MBean dependent web module
---------------------------------------------
Key: JBJMX-101
URL: http://jira.jboss.com/jira/browse/JBJMX-101
Project: JBoss JMX
Issue Type: Bug
Affects Versions: JBossAS-4.0.0
Environment: JBossAS 4.0.4.GA
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_09-b01)
Reporter: Maxim Gordienko
Environment: Sar module containing MBean
content of META-INF/jboss-service.xml
--- CUT ---
<?xml version="1.0" encoding="UTF-8"?>
<server>
<mbean code="dot.com.DummyKPBossService" name="dot.com:service=DummyService">
</mbean>
</server>
--- END CUT ---
War module dependant on MBean from Sar
content of WEB-INF/jboss-web.xml
--- CUT ---
<?xml version="1.0" encoding="UTF-8"?>
<jboss-web>
<depends>dot.com:service=DummyService"</depends>
</jboss-web>
--- END CUT ---
upon redeployment Sar module JBoss tries to redeploy War module but fail with NPE:
java.lang.NullPointerException
at org.jboss.web.WebModule.startModule(WebModule.java:82)
at org.jboss.web.WebModule.startService(WebModule.java:61)
at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
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.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
.......
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 6 months
[JBoss JIRA] Created: (JBESB-298) URL parsing in EdtFtpImpl.checkParms()
by Bernard Tison (JIRA)
URL parsing in EdtFtpImpl.checkParms()
--------------------------------------
Key: JBESB-298
URL: http://jira.jboss.com/jira/browse/JBESB-298
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Bernard Tison
Assigned To: Mark Little
I think there might be a problem with the way user/password information is parsed from the FTP URL for a FTP Gateway.
This is based on the static router quickstart example.
The jbossesb.xml contains the following provider definition:
Code:
<ftp-provider name="FTPprovider" hostname="localhost" >
<ftp-bus busid="StaticRouterFtpGW" >
<ftp-message-filter
username="ftpuser"
password="ftppassword"
passive="false"
directory="/tmp/esbInput"
input-suffix=".dat"
/>
</ftp-bus>
</ftp-provider>
This results in the following definition in the jbossesb-gateway.xml:
Code:
<Ftp-Gateway URL="ftp://ftpuser:ftppassword@localhost:/tmp/esbInput"
errorDelete="true" gatewayClass="org.jboss.soa.esb.listeners.gateway.RemoteGatewayListener"
...(non-relevant portion removed) "/>
When the gateway is initialized, the org.jboss.internal.soa.esb.util.EdtFtpImpl class will parse the URL and connect to the FTP server.
To parse the username/password out of the URL, the checkParms() method of the EdtFtpImpl class uses the following code (lines 190-198):
Code:
String[] sa = (null == url) ? null
: url.getAuthority().split(":");
m_sUser = (null!=sa) ? sa[0] :m_oParms.getAttribute(PARMS_USER);
if (null == m_sUser)
throw new Exception("No username specified for FTP");
m_sPasswd = (null!=sa) ? sa[1] :m_oParms.getAttribute(PARMS_PASSWD);
The url.getAuthority() method returns ftpuser:ftppassword@localhost, which results in m_sUser="ftpuser" and m_sPasswd="ftppassword@localhost". This should be: m_sUser="ftpuser" and m_sPasswd="ftppassword".
Suggestion for fix: use url.getUserInfo() to get the user/password out of the FTP URL. This is how it is done in the EdtFtpImpl(FTPEpr p_oP, boolean p_bConnect) constructor.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 6 months
[JBoss JIRA] Created: (JBCACHE-914) Adapt JBCACHE-913 fix for JBC 2.0
by Brian Stansberry (JIRA)
Adapt JBCACHE-913 fix for JBC 2.0
---------------------------------
Key: JBCACHE-914
URL: http://jira.jboss.com/jira/browse/JBCACHE-914
Project: JBoss Cache
Issue Type: Sub-task
Security Level: Public (Everyone can see)
Reporter: Brian Stansberry
Assigned To: Vladimir Blagojevic
Fix For: 2.0.0.GA
Need to port JBCACHE-913 fix to HEAD, where the code works differently.
Vladimir, I'm assigning this to you, because you are doing heavy lifting on state transfer and I don't want to step on you. I experimented with adding the following to StateTransferManager and calling it in setState right after the call to integrator.integrateState. That made the unit test (o.j.c.eviction.StateTransferIntegrationTest) pass. One concern I have is calling getChildren() on a node will end up pulling non-in-memory persisted nodes into RAM. A look at NodeImpl makes me think that's not the case, but that could change.
/**
* Generates EvictedEventNode notifications for all nodes of the tree. This is
* called whenever the tree is initially retrieved (state transfer)
*/
protected void notifyEvictionPolicyOfNodesCreated(Node curr)
{
Node n;
Set children;
if (curr == null) return;
Fqn fqn = curr.getFqn();
// JBCACHE-913
Region region = cache.getCacheSPI().getRegion(fqn, false);
if (region != null)
{
region.putNodeEvent(new EvictedEventNode(fqn, NodeEventType.ADD_NODE_EVENT));
}
if ((children = curr.getChildren()) != null)
{
for (Iterator it = children.iterator(); it.hasNext();)
{
n = (Node) it.next();
notifyEvictionPolicyOfNodesCreated(n);
}
}
}
Another approach would be to not bypass the interceptor chain when the integrator puts the node in the cache. That's very clean. But then we have to make sure no unwanted things are done by any interceptors.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 6 months