[JBoss JIRA] Created: (JBAS-5089) Prefix string too short
by pedalshoe (JIRA)
Prefix string too short
-----------------------
Key: JBAS-5089
URL: http://jira.jboss.com/jira/browse/JBAS-5089
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Deployment services
Affects Versions: JBossAS-5.0.0.Beta2
Environment: MS Windows XP
JDK1.5.0_10
JBoss AS 5.0.0.Beta2
Netbeans 6.0
Reporter: pedalshoe
Assigned To: Dimitris Andreadis
When trying to deploy a Visual web application from Netbeans i get: java.lang.IllegalArgumentException: Prefix string too short
19:43:01,265 ERROR [TomcatDeployer] Error during deployment: vfsfile:/C:/jboss-5.0.0.Beta2/server/default/deploy/JB.war
org.jboss.deployers.spi.DeploymentException: Failed to create web module
at org.jboss.web.deployers.AbstractWarDeployer.deploy(AbstractWarDeployer.java:405)
at org.jboss.web.deployers.AbstractWarDeployer.deploy(AbstractWarDeployer.java:78)
at org.jboss.deployers.plugins.deployers.helpers.AbstractSimpleRealDeployer.deploy(AbstractSimpleRealDeployer.java:56)
at org.jboss.deployers.plugins.deployer.AbstractSimpleDeployer.commitDeploy(AbstractSimpleDeployer.java:52)
at org.jboss.deployers.plugins.deployer.DeployerWrapper.commitDeploy(DeployerWrapper.java:170)
at org.jboss.deployers.plugins.deployment.MainDeployerImpl.commitDeploy(MainDeployerImpl.java:592)
at org.jboss.deployers.plugins.deployment.MainDeployerImpl.process(MainDeployerImpl.java:476)
at org.jboss.deployers.plugins.deployment.MainDeployerImpl.process(MainDeployerImpl.java:406)
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.aop.joinpoint.MethodInvocation.invokeTarget(MethodInvocation.java:121)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:110)
at org.jboss.profileservice.aop.MainDeployerAspect.process(MainDeployerAspect.java:53)
at org.jboss.aop.advice.org.jboss.profileservice.aop.MainDeployerAspect_z_process_31342381.invoke(MainDeployerAspect_z_process_31342381.java)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at AOPContainerProxy$0.process(AOPContainerProxy$0.java)
at org.jboss.system.server.profileservice.hotdeploy.HDScanner.scan(HDScanner.java:302)
at org.jboss.system.server.profileservice.hotdeploy.HDScanner.run(HDScanner.java:234)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:417)
at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:280)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:135)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:65)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:142)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:166)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.IllegalArgumentException: Prefix string too short
at java.io.File.createTempFile(File.java:1423)
at org.jboss.web.deployers.AbstractWarDeployer.deploy(AbstractWarDeployer.java:321)
... 28 more
19:43:01,765 WARN [HDScanner] Failed to process changes
org.jboss.deployers.spi.IncompleteDeploymentException: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):
*** DEPLOYMENTS IN ERROR: Name -> Error
vfsfile:/C:/jboss-5.0.0.Beta2/server/default/deploy/JB.war -> java.lang.IllegalArgumentException: Prefix string too short
at org.jboss.system.server.profileservice.hotdeploy.HDScanner.checkIncomplete(HDScanner.java:346)
at org.jboss.system.server.profileservice.hotdeploy.HDScanner.scan(HDScanner.java:303)
at org.jboss.system.server.profileservice.hotdeploy.HDScanner.run(HDScanner.java:234)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:417)
at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:280)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:135)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:65)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:142)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:166)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
at java.lang.Thread.run(Thread.java:595)
--
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
17 years, 6 months
[JBoss JIRA] Created: (EJBTHREE-1667) Same stateless EJB's context used from one call to another
by John Gonon (JIRA)
Same stateless EJB's context used from one call to another
----------------------------------------------------------
Key: EJBTHREE-1667
URL: https://jira.jboss.org/jira/browse/EJBTHREE-1667
Project: EJB 3.0
Issue Type: Bug
Components: EJB3 Extensions
Affects Versions: HEAD
Environment: Windows + Oracle 10
JBOSS 5.0.0.GA
Reporter: John Gonon
Fix For: HEAD
1) I have Stateless EJBs with the EJBContext defined as a @Resource and a method getting the caller's name:
public class MyBean {
@Resource
private SessionContext ejbSession = null;
private String getCallerName() {
return this.ejbSession.getCallerPrincipal().getName();
}
}
2) My client always always calls in authenticated mode
3) I execute my client once and everything goes fine
4) I execute it other times, but there, one in a while, I don't get my authenticated user but the one from a preious call.
I tracked that it was sometimes the same "EJBContextImpl" object from one call to the other. The first call to "getCallerPrincipal()" is cached, so when I use the same object the second time, it does not look for it but returns the value from a previous call.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 6 months
[JBoss JIRA] Created: (JBAS-6250) The server cannot run under a security manager when symlinks are contained within jboss home path
by Martin Malina (JIRA)
The server cannot run under a security manager when symlinks are contained within jboss home path
-------------------------------------------------------------------------------------------------
Key: JBAS-6250
URL: https://jira.jboss.org/jira/browse/JBAS-6250
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Test Suite
Environment: RHEL5 x86 Sun JDK 1.5
Reporter: Martin Malina
Assignee: Shelly McGowan
Attachments: server.log
The tests-security-manager fails to run when there are symlinks within the jboss.dist path.
[hudson@conf2 testsuite]$ ./build.sh -Dnode0=10.16.93.25 -Dnode1=10.16.93.26 -DudpGroup=227.43.88.165 -Djboss.dist=/home/hudson/eap5-as/jboss-5.0.0 tests-security-managerSearching for build.xml ...Buildfile: /qa/services/hudson/eap5-as/jboss-5.0.0-src/testsuite/build.xmltests-security-manager: [echo] Starting default with policy /qa/services/hudson/eap5-as/jboss-5.0.0-src/testsuite/output/resources/securitymgr/server.policy [echo] jboss.home.dir=/home/hudson/eap5-as/jboss-5.0.0
[echo] jboss.server.home.dir=/home/hudson/eap5-as/jboss-5.0.0/server/default
[server:start] Starting server "securitymgr", with command (start timeout is 240 seconds ):
[server:start] /qa/tools/opt/jdk1.5.0_15/bin/java -cp /home/hudson/eap5-as/jboss-5.0.0/bin/run.jar:/qa/tools/opt/jdk1.5.0_15/lib/tools.jar -Xms128m -Xmx256m -XX:MaxPermSize=512m -Djboss.home.dir=/home/hudson/eap5-as/jboss-5.0.0 -Djboss.server.home.dir=/home/hudson/eap5-as/jboss-5.0.0/server/default -Djboss.test.deploy.dir=/qa/services/hudson/eap5-as/jboss-5.0.0-src/testsuite/output/lib -Djava.security.manager -Djava.security.policy==/qa/services/hudson/eap5-as/jboss-5.0.0-src/testsuite/output/resources/securitymgr/server.policy -Djava.security.debug=failure -Djava.protocol.handler.pkgs=org.jboss.handlers.stub -Djava.net.preferIPv4Stack=true -Djava.endorsed.dirs=/home/hudson/eap5-as/jboss-5.0.0/lib/endorsed org.jboss.Main -c default -b 10.16.93.25 -g DefaultDomain -u 227.43.88.165
[server:start] Failed to start server "securitymgr" before timeout. Destroying the process.
BUILD FAILED
/qa/services/hudson/eap5-as/jboss-5.0.0-src/testsuite/build.xml:1640: Error starting server "securitymgr": Server failed to start in time; see logs.
The real path is /qa/services/hudson, but the often used symlink is /home/hudson with which it doesn't work. When I use the real path it works and there is no problem.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 6 months
[JBoss JIRA] Created: (JBPORTAL-2272) anonymous access in ldap
by Luca Stancapiano (JIRA)
anonymous access in ldap
------------------------
Key: JBPORTAL-2272
URL: https://jira.jboss.org/jira/browse/JBPORTAL-2272
Project: JBoss Portal
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Portal Identity
Affects Versions: Identity-1.0.3
Environment: jboss portal 2.7.0 final in jboss 4.2.3.GA
Reporter: Luca Stancapiano
Assignee: Luca Stancapiano
Fix For: Identity-1.1
using org.jboss.portal.identity.ldap.LDAPConnectionContext to log into the portal with LDAP I see that anonymous access is not supported. Many customers don't permit authenticated access to own ldap server. If I set into conf/ldap_identity-config.xml a configuration as:
<identity-configuration>
<datasources>
<datasource>
................
<option>
<name>adminDN</name>
<value></value>
</option>
<option>
<name>adminPassword</name>
<value></value>
</option>
.................
</datasource>
....I receive adminDN and adminPassword values as null into org.jboss.portal.identity.ldap.LDAPConnectionContext code at row 100:
env.put(Context.SECURITY_PRINCIPAL, this.getAdminDN());
env.put(Context.SECURITY_CREDENTIALS, this.getAdminPassword());
so I get a NullPointerException and I cannot to login. We can modify this code in this manner:
if (this.getAdminDN() != null)
env.put(Context.SECURITY_PRINCIPAL, this.getAdminDN());
if (this.getAdminPassword() != null)
env.put(Context.SECURITY_CREDENTIALS, this.getAdminPassword());
So we get an anonymous access into the portal
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 6 months
[JBoss JIRA] Created: (JBPORTAL-2268) profile directly from ldap
by Luca Stancapiano (JIRA)
profile directly from ldap
--------------------------
Key: JBPORTAL-2268
URL: https://jira.jboss.org/jira/browse/JBPORTAL-2268
Project: JBoss Portal
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Portal Identity
Affects Versions: 2.7.0 Final
Environment: openldap server, jboss as 4.2.3.GA, jbossportal 2.7.0
Reporter: Luca Stancapiano
Assignee: Luca Stancapiano
Fix For: 2.7.1 Final
configuring ldap_identity-config.xml file , I tried to use this ldap module configuration:
<module>
<type>UserProfile</type>
<implementation>LDAP</implementation>
</module>
instead of this default configuration:
<module>
<type>UserProfile</type>
<implementation>DELEGATING</implementation>
<config>
<option>
<name>ldapModuleJNDIName</name>
<value>java:/portal/LDAPUserProfileModule</value>
</option>
</config>
</module>
and I used in standardidentity-config.xml this module:
<module>
<type>UserProfile</type>
<implementation>LDAP</implementation>
<service-name>portal:service=Module,type=UserProfile</service-name>
<class>org.jboss.portal.identity.ldap.LDAPUserProfileModuleImpl</class>
<config>
<option>
<name>jNDIName</name>
<value>java:/portal/UserProfileModule</value>
</option>
<option>
<name>connectionJNDIName</name>
<value>java:/portal/LDAPConnectionContext</value>
</option>
<option>
<name>profileConfigFile</name>
<value>conf/identity/profile-config.xml</value>
</option>
</config>
</module>
instead of:
<module>
<!--type used to correctly map in IdentityContext registry-->
<type>UserProfile</type>
<implementation>DELEGATING</implementation>
<!--name of service and class for creating mbean-->
<service-name>portal:service=Module,type=UserProfile</service-name>
<class>org.jboss.portal.identity.DelegatingUserProfileModuleImpl</class>
<!--set of options that are set in instantiated object-->
<config>
<option>
<name>jNDIName</name>
<value>java:/portal/UserProfileModule</value>
</option>
<option>
<name>dbModuleJNDIName</name>
<value>java:/portal/DBUserProfileModule</value>
</option>
<option>
<name>profileConfigFile</name>
<value>conf/identity/profile-config.xml</value>
</option>
</config>
</module>
so I can to use directly ldap profiles without DB Delegation.
org.jboss.portal.identity.auth.IdentityLoginModule class seems to get a little bug on a point because it would a 'enabled' attribute returning as java.lang.Boolean. But you can to get only java.lang.String attributes from LDAP. So you have always a 'enabled' attribute to false and the user always is disabled when you log into the portal. To resolve this problem you could to modify this code in org.jboss.portal.identity.auth.IdentityLoginModule: 259 :
if (enabledS != null && (enabledS instanceof Boolean)) {
enabled = ((Boolean)enabledS).booleanValue();
}
in this manner:
if (enabledS != null) {
enabled = new Boolean(enabledS.toString());
}
what do you think about it?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 6 months
[JBoss JIRA] Created: (JGRP-883) Use of Math.min In GossipRouter's Socket Linger Code Causes Unexpected Results
by Jimmy Wilson (JIRA)
Use of Math.min In GossipRouter's Socket Linger Code Causes Unexpected Results
------------------------------------------------------------------------------
Key: JGRP-883
URL: https://jira.jboss.org/jira/browse/JGRP-883
Project: JGroups
Issue Type: Bug
Affects Versions: 2.7, 2.6.7, 2.5.2, 2.4.4
Reporter: Jimmy Wilson
Assignee: Jimmy Wilson
Fix For: 2.4.5, 2.6.8, 2.8
>From 2.6.7 Gossip Router Code:
/** Time (in millis) for setting SO_LINGER on sockets returned from accept(). 0 means don't set SO_LINGER */
private long linger_timeout=2000L;
...snip...
if(linger_timeout > 0) {
int linger=Math.min(1, (int)(linger_timeout / 1000));
sock.setSoLinger(true, linger);
}
This means that the socket linger timeout will always be 1 regardless of what you set exception when a millisecond value of less than one second is specified which isn't valid for a socket linger timeout anyway. Math.max should likely be used instead.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 6 months