[JBoss JIRA] (AS7-5866) Move ExistingChannelModelControllerClient to controller-client
by Brian Stansberry (JIRA)
Brian Stansberry created AS7-5866:
-------------------------------------
Summary: Move ExistingChannelModelControllerClient to controller-client
Key: AS7-5866
URL: https://issues.jboss.org/browse/AS7-5866
Project: Application Server 7
Issue Type: Task
Components: Domain Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 7.2.0.Alpha1
JConsoleCLIPlugin imports this class, bringing a dependency on jboss-as-controller into the cli module. This class doesn't need to be in controller.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years
[JBoss JIRA] (AS7-5864) Classes of a module cannot get access to the META-INF folder in its own jar/module
by John Wu (JIRA)
John Wu created AS7-5864:
----------------------------
Summary: Classes of a module cannot get access to the META-INF folder in its own jar/module
Key: AS7-5864
URL: https://issues.jboss.org/browse/AS7-5864
Project: Application Server 7
Issue Type: Bug
Components: Class Loading
Affects Versions: 7.1.1.Final
Reporter: John Wu
Assignee: David Lloyd
Currently there is absolutely no mechanism for classes of a module to get access to some META-INF/xyz files in its own jar/module, except are in META-INF/services.
This is a serious impediment when considering the installation of third party libraries as shared libraries (modules) in JBoss AS. Some frameworks may rely upon locating internal descriptors in META-INF, and if the libraries are installed as modules, the descriptors are not accessible to the framework itself. Essentially, there is no way of accessing resources under META-INF unless they are either services, or the library is packaged in the deployment.
This is the un-resolved part of issue [AS7-1928|https://issues.jboss.org/browse/AS7-1928].
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years
[JBoss JIRA] (AS7-5852) CLONE - Some script utilities don't work correctly on Windows, if $JBOSS_HOME or $JAVA_HOME variables contain space symbols
by Paul Gier (JIRA)
[ https://issues.jboss.org/browse/AS7-5852?page=com.atlassian.jira.plugin.s... ]
Paul Gier updated AS7-5852:
---------------------------
Labels: (was: eap601candidate)
> CLONE - Some script utilities don't work correctly on Windows, if $JBOSS_HOME or $JAVA_HOME variables contain space symbols
> ---------------------------------------------------------------------------------------------------------------------------
>
> Key: AS7-5852
> URL: https://issues.jboss.org/browse/AS7-5852
> Project: Application Server 7
> Issue Type: Bug
> Components: Scripts
> Environment: Windows Vista 6, Windows 7, Windows XP
> Reporter: Vladimir Rastseluev
> Assignee: Paul Gier
> Fix For: 7.2.0.Alpha1, 7.1.4.Final (EAP)
>
>
> Utilities vault.bat and jconsole.bat don't work correctly, if path to $JAVA_HOME or $JBOSS_HOME (directory, where EAP placed) contains space symbol, e.g. $JAVA_HOME="C:\Program Files\java".
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years
[JBoss JIRA] (JGRP-1531) Message Headers Not Encrypted
by Edward Sutter (JIRA)
Edward Sutter created JGRP-1531:
-----------------------------------
Summary: Message Headers Not Encrypted
Key: JGRP-1531
URL: https://issues.jboss.org/browse/JGRP-1531
Project: JGroups
Issue Type: Bug
Affects Versions: 3.1
Reporter: Edward Sutter
Assignee: Bela Ban
I am running 3.1.0-FINAL and have observed that message headers are not
being encrypted even though the "encrypt_entire_message" option is set to
true. After stepping through the code I suspect that the headers are being
appended to the output stream that is used at the TCP layer.
Specifically...
org.jgroups.protocols.ENCRYPT.sendDown(Event evt) will encrypt the message
(including headers) and send down the stack via this block...
private void sendDown(Event evt) throws Exception {
...
EncryptHeader hdr=new EncryptHeader(EncryptHeader.ENCRYPT, getSymVersion());
hdr.encrypt_entire_msg=this.encrypt_entire_message;
if(encrypt_entire_message) {
byte[] serialized_msg=Util.streamableToByteBuffer(msg);
byte[] encrypted_msg=encryptMessage(symEncodingCipher,
serialized_msg,
0,
serialized_msg.length);
Message tmp=msg.copy(false); // we need to preserve headers which may already be present
tmp.setBuffer(encrypted_msg);
if(tmp.getSrc() == null)
tmp.setSrc(local_addr);
tmp.putHeader(this.id, hdr);
passItDown(new Event(Event.MSG, tmp));
return;
}
...
}
Note that the unencrypted headers are preserved even though the encrypted
headers are included in "encrypted_msg".
Later on, org.jgroups.protocols.TP.writeMessage(Message msg, DataOutputStream dos, boolean multicast) will call
Message.writeTo(DataOutput) to build the message that is sent. The problem
seems to be that Message.writeTo(DataOutput) will include the encrypted
byte[] (expected) but also include the unencrypted headers that were
preserved.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years
[JBoss JIRA] (AS7-2516) Arquillian throws OutOfMemoryError: PermGen space after deploying several big wars on JBoss 7
by Geoffrey De Smet (Created) (JIRA)
Arquillian throws OutOfMemoryError: PermGen space after deploying several big wars on JBoss 7
---------------------------------------------------------------------------------------------
Key: AS7-2516
URL: https://issues.jboss.org/browse/AS7-2516
Project: Application Server 7
Issue Type: Bug
Components: Test Suite
Affects Versions: 7.0.2.Final
Reporter: Geoffrey De Smet
Assignee: Andrew Rubinger
Priority: Minor
Here's the proof (that build is saved forever):
https://hudson.qa.jboss.com/hudson/view/Drools%20jBPM/job/guvnor/1161/con...
Our war is apparently so big, that the 3th deployment fails with PermGen.
A few tests later it even hangs forever (until it times out)
{code}
10:41:56,393 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/dc25ad71-9358-412e-8a90-c4471cb3422f].[ArquillianServletRunner]] (http--127.0.0.1-8080-2) Servlet.service() for servlet ArquillianServletRunner threw exception: java.lang.OutOfMemoryError: PermGen space
{code}
How to reproduce?
=================
git clone git@github.com:droolsjbpm/guvnor.git guvnor
cd guvnor
mvn clean install -DskipTests
cd guvnor-webapp
gedit src/test/resources/arquillian.xml
// remove the maxTestClassesBeforeRestart property
mvn test
Using arquillian 1.0.0.CR5 and jboss 7.0.2.
Workaround: use maxTestClassesBeforeRestart = 1.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years
[JBoss JIRA] (AS7-5862) Do not ignore security annotations and deployment descriptor configurations on EJBs in the absence of explicit security domain configuration
by Josef Cacek (JIRA)
Josef Cacek created AS7-5862:
--------------------------------
Summary: Do not ignore security annotations and deployment descriptor configurations on EJBs in the absence of explicit security domain configuration
Key: AS7-5862
URL: https://issues.jboss.org/browse/AS7-5862
Project: Application Server 7
Issue Type: Feature Request
Components: EJB
Affects Versions: 7.1.2.Final (EAP)
Reporter: Josef Cacek
Assignee: jaikiran pai
Fix For: 7.2.0.Alpha1
Consider the following example:
{code}
@Stateless
public class SecureBean
{
@RolesAllowed("role1")
public void restrictedRoles()
{
...
}
@DenyAll
public void denyEveryone()
{
...
}
}
{code}
Notice that the bean methods use EJB security annotations to restrict access *however* the bean doesn't have any explicit @SecurityDomain configured (not even in jboss-ejb3.xml). Right now, AS7 ignores the security restriction on that bean allows everyone to invoke on it, as if security wasn't configured for that bean. This has confused users who expect the invocations to fail since they have used the javax.ejb.* security annotations to restrict access. Many users have asked for a feature where the security domain is defaulted (if not explicitly specified) in cases like this.
This JIRA is expected to introduce this feature in AS 7.2.x
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years
[JBoss JIRA] Created: (JBAS-6326) InterruptedException on shutdown
by Jeff Yu (JIRA)
InterruptedException on shutdown
--------------------------------
Key: JBAS-6326
URL: https://jira.jboss.org/jira/browse/JBAS-6326
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: JCA service
Affects Versions: JBossAS-4.2.2.GA
Reporter: Jeff Yu
Assignee: Jeff Zhang
Priority: Minor
I see the following exception on shutdown with either default, all, production servers (using all's log4j configuration). I'm not sure it is necessary for users to see. Probably needs to be changed to DEBUG level if really not relevant.
09:07:59,647 WARN [NewMsgsWorker] Interrupted waiting for new msg check
java.lang.InterruptedException
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:474)
at EDU.oswego.cs.dl.util.concurrent.Semaphore.acquire(Semaphore.java:108)
at EDU.oswego.cs.dl.util.concurrent.SemaphoreControlledChannel.take(SemaphoreControlledChannel.java:131)
at org.jboss.resource.adapter.mail.inflow.NewMsgsWorker.run(NewMsgsWorker.java:75)
at org.jboss.resource.work.WorkWrapper.execute(WorkWrapper.java:204)
at org.jboss.util.threadpool.BasicTaskWrapper.run(BasicTaskWrapper.java:275)
at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:756)
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: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years