[JBoss JIRA] (JBDS-3071) JBDS Installer shouldn't contain source features/plugins
by Denis Golovin (JIRA)
[ https://issues.jboss.org/browse/JBDS-3071?page=com.atlassian.jira.plugin.... ]
Denis Golovin commented on JBDS-3071:
-------------------------------------
{quote}b) put these 3 features in the installer so that the installer contents == the update site contents (except for sources){quote}
This is not needed, because first, even if you add them it doesn't make installer content the same as update site content, second, installer's update site used to materialize product during installation is never used after taht, so if additional features required they going to be installed from remote JBDS p2 repository.
Please, revert PR https://github.com/jbdevstudio/jbdevstudio-product/pull/202.
> JBDS Installer shouldn't contain source features/plugins
> --------------------------------------------------------
>
> Key: JBDS-3071
> URL: https://issues.jboss.org/browse/JBDS-3071
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: installer
> Affects Versions: 8.0.0.Beta2
> Reporter: Fred Bricon
> Assignee: Nick Boldt
>
> {quote}
> So the basic JBDS installer is 70MB fatter. From my understanding it's because we now ship a *huge* forge2 runtime (50MB), Tern, the JVM Monitor and probably some other minor stuff.
> Fair enough. But do we *really* need to add all the source features/plugins to the installer? *If* we're legally bound to provide sources for JBoss plugins, couldn't we provide them via an other way? (p2 only).
> I reckon we could save ~37 MB by not shipping sources in the installer. I know storage is cheap and d/l speeds are faster but that's not an excuse.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (JBIDE-17700) Cannot deploy jsf war with eclipse luna and jboss 7.1.x
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-17700?page=com.atlassian.jira.plugi... ]
Rob Stryker commented on JBIDE-17700:
-------------------------------------
The code that is being run to find the class is:
{code}
public static synchronized KeyManager getInstance() {
if (keyManager != null)
return keyManager;
final String cn = System.getProperty(
"de.schlichtherle.key.KeyManager",
getDefaultKeyManagerClassName());
try {
final Class c = Thread.currentThread()
.getContextClassLoader().loadClass(cn);
keyManager = (KeyManager) c.newInstance();
} catch (RuntimeException ex) {
throw ex;
} catch (Exception ex) {
throw new UndeclaredThrowableException(ex);
}
return keyManager;
}
{code}
I can't know for sure why this is happening, but, let's assume that the publish event is starting in a Job, and jobs are run by workers. Perhaps archives.core should be sure to 'start' when any of its classes are referenced, and archives.core's start method should be sure to initialize the framework properly?
> Cannot deploy jsf war with eclipse luna and jboss 7.1.x
> -------------------------------------------------------
>
> Key: JBIDE-17700
> URL: https://issues.jboss.org/browse/JBIDE-17700
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Environment: Win 7, Eclilpse Luna, JBoss Tools (via market place)
> Reporter: Oliver Pfau
> Priority: Critical
>
> When I publish my war to jboss 7.1 the following error occurs:
> An internal error occurred during: "Publishing to JBoss AS 7.1...".
> Could not initialize class de.schlichtherle.io.ArchiveControllers
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (JBIDE-17700) Cannot deploy jsf war with eclipse luna and jboss 7.1.x
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/JBIDE-17700?page=com.atlassian.jira.plugi... ]
Rob Stryker commented on JBIDE-17700:
-------------------------------------
So... I've come nowhere in terms of replication, but I think it's pretty clear the issue isn't related to signed jars or anytthing of that nature. This is all done when truezip is initializing itself. The Servertools publishers issue a truezip.umount() command to start. This command basically tells truezip to write any changes it has to disk, but the evidence shows pretty strongly that this is the first call done to the framework, and it hasn't yet initialized.
Execution flows to KeyManager.getInstance(), which is just one of the initialization steps in TrueZip.
Here's the juicy part:
{code}
ContextFinder.loadClass(String, boolean) line: 119
ContextFinder(ClassLoader).loadClass(String) line: 358
KeyManager.getInstance() line: 117
ArchiveControllers$ShutdownHook.<init>() line: 388
{code}
This is the stacktrace *I* see. It's not using org.codehaus.plexus.classworlds.realm.ClassRealm to load the class when *I* run it in my unit tests or when I trace through my workspace, but in your stacktrace, it is, and the org.codehaus.plexus.classworlds.realm.ClassRealm classloader can't find the class it needs to initialize properly.
That's all I've got for now though.
> Cannot deploy jsf war with eclipse luna and jboss 7.1.x
> -------------------------------------------------------
>
> Key: JBIDE-17700
> URL: https://issues.jboss.org/browse/JBIDE-17700
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Environment: Win 7, Eclilpse Luna, JBoss Tools (via market place)
> Reporter: Oliver Pfau
> Priority: Critical
>
> When I publish my war to jboss 7.1 the following error occurs:
> An internal error occurred during: "Publishing to JBoss AS 7.1...".
> Could not initialize class de.schlichtherle.io.ArchiveControllers
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (JBDS-3071) JBDS Installer shouldn't contain source features/plugins
by Denis Golovin (JIRA)
[ https://issues.jboss.org/browse/JBDS-3071?page=com.atlassian.jira.plugin.... ]
Denis Golovin commented on JBDS-3071:
-------------------------------------
IMO they should not be added nether to pom.xml for mirroring not to product feature, fact is they never were installed as through installer.jar. Installer materialize only JBDS Branded Product Feature and nothing else. They just add weight to installer jar :)
> JBDS Installer shouldn't contain source features/plugins
> --------------------------------------------------------
>
> Key: JBDS-3071
> URL: https://issues.jboss.org/browse/JBDS-3071
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: installer
> Affects Versions: 8.0.0.Beta2
> Reporter: Fred Bricon
> Assignee: Nick Boldt
> Fix For: 8.0.0.Beta3
>
>
> {quote}
> So the basic JBDS installer is 70MB fatter. From my understanding it's because we now ship a *huge* forge2 runtime (50MB), Tern, the JVM Monitor and probably some other minor stuff.
> Fair enough. But do we *really* need to add all the source features/plugins to the installer? *If* we're legally bound to provide sources for JBoss plugins, couldn't we provide them via an other way? (p2 only).
> I reckon we could save ~37 MB by not shipping sources in the installer. I know storage is cheap and d/l speeds are faster but that's not an excuse.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (JBDS-3022) Iintermittent/Recurring Crash of JBDS 7.1.1 - when defining a new server runtime
by Snjezana Peco (JIRA)
[ https://issues.jboss.org/browse/JBDS-3022?page=com.atlassian.jira.plugin.... ]
Snjezana Peco updated JBDS-3022:
--------------------------------
Fix Version/s: 8.0.x
(was: 8.0.0.Beta3)
> Iintermittent/Recurring Crash of JBDS 7.1.1 - when defining a new server runtime
> --------------------------------------------------------------------------------
>
> Key: JBDS-3022
> URL: https://issues.jboss.org/browse/JBDS-3022
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: runtime-detection, upstream
> Affects Versions: 7.1.1.GA, 8.0.0.Beta2
> Environment: uname -a
> Linux ldimaggi.csb 2.6.32-431.11.2.el6.x86_64 #1 SMP Mon Mar 3 13:32:45 EST 2014 x86_64 x86_64 x86_64 GNU/Linux
> cat /etc/redhat-release
> Red Hat Enterprise Linux Workstation release 6.5 (Santiago)
> java -version
> java version "1.7.0_51"
> OpenJDK Runtime Environment (rhel-2.4.4.1.el6_5-x86_64 u51-b02)
> OpenJDK 64-Bit Server VM (build 24.45-b08, mixed mode)
> Reporter: Len DiMaggio
> Assignee: Snjezana Peco
> Fix For: 4.1.x, 8.0.x
>
> Attachments: Crash.mov, hs_error.log
>
>
> Iintermittent/Recurring Crash of JBDS 7.1.1 - when defining a new server runtime
> See attached screencast - crash occurs at the 14 second mark - seeing this 50-80% of the time on one RHEL 6.5 system.
> Steps to repeat:
> * install JBDS 7.1.1
> jbdevstudio-product-eap-universal-7.1.1.GA-v20140314-2145-B688.jar
> -or-
> jbdevstudio-product-universal-7.1.1.GA-v20140314-2145-B688.jar
> * Create a new server runtime - at the point that Next> is pressed after selecting the runtime version, the crash occurs
> * Only seeing this with JBDS - not Eclipse Kepler + JBTools
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (JBIDE-17297) JBoss Central crashes and brings down JBDS 8 Beta 1
by Snjezana Peco (JIRA)
[ https://issues.jboss.org/browse/JBIDE-17297?page=com.atlassian.jira.plugi... ]
Snjezana Peco updated JBIDE-17297:
----------------------------------
Fix Version/s: 4.2.x
(was: 4.2.0.Beta3)
> JBoss Central crashes and brings down JBDS 8 Beta 1
> ---------------------------------------------------
>
> Key: JBIDE-17297
> URL: https://issues.jboss.org/browse/JBIDE-17297
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: central, upstream
> Affects Versions: 4.2.0.Beta1
> Environment: JBDS 8 Beta1, Fedora 20, multiple JVMs - Oracle JDK 8 (1.8.0_05), Oracle JDK 7 (1.7.0_55)
> Reporter: Vineet Reynolds
> Assignee: Snjezana Peco
> Priority: Critical
> Fix For: 4.2.x
>
>
> I encounter crashes in JBDS 8 Beta 1, when JBDS Central is loaded.
> The following stack trace was recorded:
> {noformat}
> !MESSAGE Cannot load bundle com.jboss.jbds.central.discovery_8.0.0.Beta1_v20140408_2329_B102.jar_115481158031680986.jar from url /home/vreynolds/workspaces/JBDS8Workspaces/WFK/.metadata/.plugins/org.jboss.tools.central/proxyWizards/1400494422919/com.jboss.jbds.central.discovery_8.0.0.Beta1_v20140408_2329_B102.jar_115481158031680986.jar: zip file is empty
> !STACK 0
> java.util.zip.ZipException: zip file is empty
> at java.util.zip.ZipFile.open(Native Method)
> at java.util.zip.ZipFile.<init>(ZipFile.java:220)
> at java.util.zip.ZipFile.<init>(ZipFile.java:150)
> at java.util.jar.JarFile.<init>(JarFile.java:166)
> at java.util.jar.JarFile.<init>(JarFile.java:130)
> at org.jboss.tools.project.examples.internal.discovery.xpl.DiscoveryRegistryStrategy.processBundle(DiscoveryRegistryStrategy.java:137)
> at org.jboss.tools.project.examples.internal.discovery.xpl.DiscoveryRegistryStrategy.processBundles(DiscoveryRegistryStrategy.java:126)
> at org.jboss.tools.project.examples.internal.discovery.xpl.DiscoveryRegistryStrategy.onStart(DiscoveryRegistryStrategy.java:78)
> at org.eclipse.core.internal.registry.ExtensionRegistry.<init>(ExtensionRegistry.java:725)
> at org.jboss.tools.project.examples.internal.discovery.xpl.ExternalBundleDiscoveryStrategy.performDiscovery(ExternalBundleDiscoveryStrategy.java:125)
> at org.jboss.tools.project.examples.internal.discovery.ChainedDiscoveryStrategy.performDiscovery(ChainedDiscoveryStrategy.java:62)
> at org.eclipse.mylyn.internal.discovery.core.model.ConnectorDiscovery.performDiscovery(ConnectorDiscovery.java:114)
> at org.jboss.tools.central.internal.discovery.wizards.ProxyWizardManager.loadWizards(ProxyWizardManager.java:101)
> at org.jboss.tools.central.internal.discovery.wizards.ProxyWizardManager.getProxyWizards(ProxyWizardManager.java:121)
> at org.jboss.tools.central.editors.GettingStartedPage.getProxyWizards(GettingStartedPage.java:555)
> at org.jboss.tools.central.editors.GettingStartedPage.access$11(GettingStartedPage.java:553)
> at org.jboss.tools.central.editors.GettingStartedPage$5.run(GettingStartedPage.java:511)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53)
> !SESSION 2014-05-19 15:45:30.045 -----------------------------------------------
> {noformat}
> To recover from this, I needed to be quick enough to uncheck the "load on startup" checkbox to disable JBoss Central. Re-opening JBoss Central at any other point in time causes the crash to be reproducible.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months