Menu
▾
▴
jboss-dev-forums — The jboss development forum posts
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
(157) |
May
(789) |
Jun
(608) |
Jul
(554) |
Aug
(868) |
Sep
(654) |
Oct
(994) |
Nov
(803) |
Dec
(982) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
(1006) |
Feb
(1054) |
Mar
(1345) |
Apr
(1305) |
May
(1392) |
Jun
(1016) |
Jul
(265) |
Aug
(1) |
Sep
(8) |
Oct
(9) |
Nov
(8) |
Dec
(19) |
| 2007 |
Jan
(20) |
Feb
(10) |
Mar
(20) |
Apr
(8) |
May
(4) |
Jun
(1) |
Jul
(6) |
Aug
(3) |
Sep
(6) |
Oct
(12) |
Nov
(7) |
Dec
(13) |
| 2008 |
Jan
(5) |
Feb
(4) |
Mar
(34) |
Apr
(32) |
May
(22) |
Jun
(21) |
Jul
(30) |
Aug
(18) |
Sep
(30) |
Oct
(23) |
Nov
(86) |
Dec
(51) |
| 2009 |
Jan
(25) |
Feb
(26) |
Mar
(34) |
Apr
(47) |
May
(38) |
Jun
(25) |
Jul
(36) |
Aug
(9) |
Sep
(8) |
Oct
(10) |
Nov
(4) |
Dec
(17) |
| 2010 |
Jan
(7) |
Feb
(9) |
Mar
(26) |
Apr
(49) |
May
(52) |
Jun
(48) |
Jul
(39) |
Aug
(27) |
Sep
(9) |
Oct
(14) |
Nov
(7) |
Dec
(10) |
| 2011 |
Jan
(12) |
Feb
(9) |
Mar
(17) |
Apr
(33) |
May
(39) |
Jun
(36) |
Jul
(29) |
Aug
(26) |
Sep
(29) |
Oct
(38) |
Nov
(35) |
Dec
(27) |
| 2012 |
Jan
(20) |
Feb
(34) |
Mar
(29) |
Apr
(33) |
May
(45) |
Jun
(46) |
Jul
(50) |
Aug
(35) |
Sep
(55) |
Oct
(68) |
Nov
(79) |
Dec
(45) |
| 2013 |
Jan
(67) |
Feb
(20) |
Mar
(55) |
Apr
(52) |
May
(25) |
Jun
(25) |
Jul
(34) |
Aug
(27) |
Sep
(21) |
Oct
(21) |
Nov
(19) |
Dec
(12) |
| 2014 |
Jan
(10) |
Feb
(8) |
Mar
(13) |
Apr
(18) |
May
(36) |
Jun
(26) |
Jul
(17) |
Aug
(19) |
Sep
(13) |
Oct
(8) |
Nov
(7) |
Dec
(5) |
| 2015 |
Jan
(11) |
Feb
(2) |
Mar
(13) |
Apr
(15) |
May
(7) |
Jun
(2) |
Jul
(4) |
Aug
(3) |
Sep
(3) |
Oct
|
Nov
(2) |
Dec
(1) |
| 2016 |
Jan
(3) |
Feb
(5) |
Mar
(19) |
Apr
(34) |
May
(9) |
Jun
(10) |
Jul
(5) |
Aug
(10) |
Sep
(5) |
Oct
(11) |
Nov
(19) |
Dec
(7) |
| 2017 |
Jan
(4) |
Feb
(4) |
Mar
(8) |
Apr
(5) |
May
(12) |
Jun
(5) |
Jul
(11) |
Aug
(4) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <ad...@jb...> - 2005-06-06 17:59:37
|
If we are to have an alias scheme, I would prefer it to have some sort of "type" that could be used to identify mbean automatically, e.g. | <depends type="Queue" name="testQueue"/> | is | jboss.mq.destinations:service=Queue,name=testQueue | Otherwise you're going to either need to explicity declare aliases in the MBeans or get the relevent MBeans to populate the alias database in such as a way that they don't conflict. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880481#3880481 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880481 |
|
From: <ad...@jb...> - 2005-06-06 17:55:31
|
"sco...@jb..." wrote : If we add a full object name alias notion to the jmx mc service layer, the depends notion can be the same as jbas5 in terms of a simple name. | I'm not sure I like the idea of introducting yet another arbitrary naming space. Though I do agree that logical names are important. I would prefer the "alias notion" to be based on something more concrete, like. a contract rather than just an ad hoc notion. | <mbean code="org.jboss.tm.TransactionManagerService" | name="jboss:service=TransactionManager" | xmbean-dd="resource:xmdesc/TransactionManagerService-xmbean.xml"> | <attribute name="TransactionTimeout">300</attribute> | <!-- set to false to disable transaction demarcation over IIOP --> | <attribute name="GlobalIdsEnabled">true</attribute> | <depends optional-attribute-name="XidFactory">jboss:service=XidFactory</depends> | <!-- depends optional-attribute-name="RecoveryLogger" proxy-type="org.jboss.tm.recovery.RecoveryLoggerInstance">jboss:service=RecoveryLogger</depends--> | </mbean> | | <bean interface="javax.transaction.TransactionManager" | <factory bean="jboss:service=TransactionManager" method="getInstance"/> | </bean> | | <bean name="MyBean"> | <property name="TM"><inject interface="javax.transaction.TransactionManager"/></property> | </bean> | And ideally, this type of monomorphic (one implementor of the contract) behaviour would be "automatic" without the too much need for explicit declaration. | <bean name="MyBean"> | <property name="TM"><inject/></property> <!-- optional? --> | </bean> | There are other dependencies that are not directly related to injection, but have some logical component: | <deployment> | <depends implementation="javax.jms" version="1.5"/> | <bean name="MyBean"/> | </deployment> | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880480#3880480 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880480 |
|
From: amanweb <nu...@jb...> - 2005-06-06 17:25:12
|
Hi, i want to know the correct way to develop a custom portal(making my own portlets and changing the layout) for my company, based on Jboss Portal. What should i do? Get the source code or the binary? Hope some tips... tnks ps: Sorry for my intermediate english View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880471#3880471 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880471 |
|
From: <sco...@jb...> - 2005-06-06 17:18:38
|
Also note that the inclusion of the '.' and '-' in the suffix is important as there has been some supurious deployment exceptions when unqualified suffixes were found, for example, "notajbar" getting deployed as a ".jbar". View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880467#3880467 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880467 |
|
From: <sco...@jb...> - 2005-06-06 17:09:42
|
No, that is correct, the war deployer does not have a subdeployment notion currently. We did waffle a bit when adding web services, but ultimately the integration went into the tomcat deployer. The issue with the war is that it does need to know more about its deployment structure to properly configure the myriad of paths tomcat needs and navigation depends on whether there is a packed/unpacked deployment. I do think the only real issues are to fix the hard coded subdeployment list in the ear deployer, and then to push the accepts implementation to the subdeployer support level based on the directory free list of suffixes the subdeployer implementation supports. So given a .jbar, and a -bean.xml deployment suffix list, ".jbar", ".jbar/" and "-bean.xml" are accepted by the bean deployer. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880465#3880465 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880465 |
|
From: <sco...@jb...> - 2005-06-06 16:59:03
|
If we add a full object name alias notion to the jmx mc service layer, the depends notion can be the same as jbas5 in terms of a simple name. The only scenario where I can see needing to specify a loader-repository is if a standalone bean deployment needs to use the scoped namespace of another legacy deployment. This is a rather exotic deployment for most users. If your just talking about allowing a standalone bean deployment to use a scoped class loader, can't we just use a bean reference to a class loader configuration and embed the configuration in the target bean? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880462#3880462 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880462 |
|
From: <ad...@jb...> - 2005-06-06 16:56:49
|
So the main issue is to fix the ear deployer to only accept the explicitly defined modules in application.xml and jboss-aop.xml If that is correct, I'll create a subtask off JBAS-1801 and fix it myself. I think that whether the explicitly named deployment actually has an installed deployer is not an issue relevent to the EARDeployer. It will try to deploy the subdeployment and it might fail if no installed deployer recognises it. I'm not sure I get the issue with the war deployments since they don't accept any subdeployments? Or has that changed? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880461#3880461 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880461 |
|
From: <sco...@jb...> - 2005-06-06 16:50:41
|
That alias form does not add much. What I have wanted for some time is a syntax like: | <depends alias="HelloBeans" /> | to remove the need to deal with object names. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880460#3880460 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880460 |
|
From: <sco...@jb...> - 2005-06-06 16:42:37
|
I have created a seperate thread in the deployers forum for the JBAS-1801 sidetrack. http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880454 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880458#3880458 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880458 |
|
From: <sco...@jb...> - 2005-06-06 16:38:47
|
Background: http://jira.jboss.com/jira/browse/JBAS-1801 http://www.jboss.org/index.html?module=bb&op=viewtopic&t=64874 We need to move toward url handling being a vfs aspect of the deployment layer. In the interim, we need to cleanup the subdeployment processing in 4.0.x to avoid inconsistencies in behavior as new deployers are added. Repeating the forum reference statement, most deployers can rely on the packing/unpacking done by the MainDeployer/Subdeployment support layers and should not have to worry about details of whether they can handle an archive or a directory as the DeploymentInfo.localUrl and localCl should be configured correctly for them. Deployers like the ear and war deployers are the problems since they have non-trivial heiarchical structures. I think the main problem with consistency right now is the ear deployer's notion of overriding the subdeployment processing. First, the list simply needs to be externalized. Beyond that, the notion of restricting subdeployments to the application.xml jars is broken because we allow arbitrary subdeployments to be introduced via the jboss-app.xml descriptor. We should just be checking the subdeployment against the list of archives specified via the application.xml or jboss-app.xml descriptors. Really, I don't think we care at all about the suffix, so the externalization of acceptable suffixes is should be irrelevant. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880454#3880454 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880454 |
|
From: <sco...@jb...> - 2005-06-06 16:28:09
|
Since there is some discussion that could result in .bar being a j2ee suffix, I would suggest jbar for java bean archive. As part of adding a new deployer, I would like to address the suffix handling issue that showed up with the har deployer in JBAS-1801. All deployers should just be declaring their suffixes and the recognization/unpacking issues handed by the base support classes to avoid the inconsistency showing up now. Adrian says in response to the latter issue: anonymous wrote : | Given that we don't have the VFS in JBoss4 (the VFS would potentially allow signing of directories as well) what is the final decision on what should be supported by each layer. | | I would think the packed/unpacked issue should be transparent to the deployers and the deployment descriptors? | e.g. if my deployer accepts .foo it should accept .foo/ without having to explicitly say so. | Most deployers can rely on the packing/unpacking done by the MainDeployer and should not have to worry about details of whether they can handle an archive or a directory as the DeploymentInfo.localUrl and localCl should be configured correctly for them. Deployers like the ear and war deployers are the problems since they have non-trivial heiarchical structures. I think the main problem with consistency right now is the ear deployer's notion of overriding the subdeployment processing. First, the list simply needs to be externalized. Beyond that, the notion of restricting subdeployments to the application.xml jars is broken because we allow arbitrary subdeployments to be introduced via the jboss-app.xml descriptor. We should just be checking the subdeployment against the list of archives specified via the application.xml or jboss-app.xml descriptors. Really, I don't think we care at all about the suffix. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880450#3880450 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880450 |
|
From: Adrian B. <adr...@jb...> - 2005-06-06 16:13:16
|
Given that we don't have the VFS in JBoss4 (the VFS would potentially allow signing of directories as well) what is the final decision on what should be supported by each layer. I would think the packed/unpacked issue should be transparent to the deployers and the deployment descriptors? e.g. if my deployer accepts .foo it should accept .foo/ without having to explicitly say so. On Mon, 2005-06-06 at 11:50, Scott M Stark wrote: > Since there is some discussion that could result in .bar being a j2ee > suffix, I would suggest jbar for java bean archive. > > As part of adding a new deployer, I would like to address the suffix > handling issue that showed up with the har deployer in JBAS-1801. All > deployers should just be declaring their suffixes and the > recognization/unpacking issues handed by the base support classes to > avoid the inconsistency showing up now. > > > -----Original Message----- > > From: jbo...@li... > > [mailto:jbo...@li...] On > > Behalf Of ad...@jb... > > Sent: Monday, June 06, 2005 8:43 AM > > To: jbo...@li... > > Subject: [Jboss-dev-forums] [Design the new POJO > > MicroContainer] - JBoss Bean Deployer - deployment names > > > > This is really one for the "naming nazis" :-) > > > > What do you want to call the bean deployments? > > > > I'd suggest something like: > > Archive Name: mybeans.bar > > Archive MetaData: META-INF/jboss-beans.xml NonArchive > > MetaData: *-beans.xml > > > > I could also allow these to be changed on the deployer itself > > through JMX attributes? > > > > View the original post : > > http://www.jboss.org/index.html?module=bb&op=viewtopic&p=38804 > > 33#3880433 > > > > Reply to the post : > > http://www.jboss.org/index.html?module=bb&op=posting&mode=repl > > y&p=3880433 > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by: NEC IT Guy Games. How far > > can you shotput a projector? How fast can you ride your desk > > chair down the office luge track? > > If you want to score the big prize, get to know the little guy. > > Play to win an NEC 61" plasma display: > > http://www.necitguy.com/?r=20 > > _______________________________________________ > > Jboss-dev-forums mailing list > > Jbo...@li... > > https://lists.sourceforge.net/lists/listinfo/jboss-dev-forums > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput > a projector? How fast can you ride your desk chair down the office luge track? > If you want to score the big prize, get to know the little guy. > Play to win an NEC 61" plasma display: http://www.necitguy.com/?r > _______________________________________________ > Jboss-dev-forums mailing list > Jbo...@li... > https://lists.sourceforge.net/lists/listinfo/jboss-dev-forums -- xxxxxxxxxxxxxxxxxxxxxxxx Adrian Brock Chief Scientist JBoss Inc. xxxxxxxxxxxxxxxxxxxxxxxx |
|
From: <ad...@jb...> - 2005-06-06 16:03:43
|
This issue is really a simple version of something that I wanted to have on running on top of the kernel. i.e. the notion of multiple "kernels" in different application contexts that can delegate to each other. This was something that was started in system2, see org.jboss.beans but not really developed to anything useable. I'm not sure that this is something we are going to resolve fully in the initial release. The first issue is kernel sharing which can be viewed in two different ways: 1) Kernel Isolation i.e. which kernel to use * JVM level * Top level deployment * My deployment this will probably require some link into the classloading config to make sense unless we just let users do what they want and let them sort it out themselves if the kernels are trying to share across incompatible classloaders 2) Named kernels i.e. we let people share kernels by naming the kernels in a similar way to loader repositories The second issue is "stacking" kernels, i.e. should the kernel delegate to parent or look locally first, and what is the kernel's parent(s)? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880440#3880440 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880440 |
|
From: <ad...@jb...> - 2005-06-06 15:54:44
|
I know we said we weren't going to worry too much about JMX integration in JBoss4. But it should be possible to provide some basic integration at the deployment level, e.g. | <?xml version="1.0" encoding="UTF-8"?> | | <deployment xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" | xsi:schemaLocation="urn:jboss:bean-deployer bean-deployer_1_0.xsd" | xmlns="urn:jboss:bean-deployer"> | | <loader-repository> | dot.com:loader=test | </loader-repository> | | <depends>jboss:service=TransactionManager</depends> | | <bean name="Name1" class="test.Hello"> | <property name="prop">Property</property> | </bean> | </deployment> | | Where "loader-repository" and "depends" are the standard JMX MC notions. The main issue is how to do this while minimizing the "kludges" we have to support for backwards compatibility when there is a real integration between the JMX and POJO MCs. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880437#3880437 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880437 |
|
From: Scott M S. <sco...@jb...> - 2005-06-06 15:51:00
|
Since there is some discussion that could result in .bar being a j2ee suffix, I would suggest jbar for java bean archive. As part of adding a new deployer, I would like to address the suffix handling issue that showed up with the har deployer in JBAS-1801. All deployers should just be declaring their suffixes and the recognization/unpacking issues handed by the base support classes to avoid the inconsistency showing up now.=20 > -----Original Message----- > From: jbo...@li...=20 > [mailto:jbo...@li...] On=20 > Behalf Of ad...@jb... > Sent: Monday, June 06, 2005 8:43 AM > To: jbo...@li... > Subject: [Jboss-dev-forums] [Design the new POJO=20 > MicroContainer] - JBoss Bean Deployer - deployment names >=20 > This is really one for the "naming nazis" :-) >=20 > What do you want to call the bean deployments? >=20 > I'd suggest something like: > Archive Name: mybeans.bar > Archive MetaData: META-INF/jboss-beans.xml NonArchive=20 > MetaData: *-beans.xml >=20 > I could also allow these to be changed on the deployer itself=20 > through JMX attributes? >=20 > View the original post :=20 > http://www.jboss.org/index.html?module=3Dbb&op=3Dviewtopic&p=3D38804 > 33#3880433 >=20 > Reply to the post :=20 > http://www.jboss.org/index.html?module=3Dbb&op=3Dposting&mode=3Drepl > y&p=3D3880433 >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by: NEC IT Guy Games. How far=20 > can you shotput a projector? How fast can you ride your desk=20 > chair down the office luge track? > If you want to score the big prize, get to know the little guy. =20 > Play to win an NEC 61" plasma display:=20 > http://www.necitguy.com/?r=3D20=20 > _______________________________________________ > Jboss-dev-forums mailing list > Jbo...@li... > https://lists.sourceforge.net/lists/listinfo/jboss-dev-forums >=20 |
|
From: <ad...@jb...> - 2005-06-06 15:48:57
|
To allow jboss bean deployments to work in the jmx lifecycle I've made the bean deployer use "Manual" mode. Since the deployments are MBeans under the control of the ServiceController, you can use these names like you would any other dependency. e.g. | <depends>jboss.beans:service=JBossBeanDeployment,name='mybeans.bar'</depends> | While this provides fairly direct access to the dependency being specified, do you think it would be good idea to provide a logical override of the name, e.g. | <?xml version="1.0" encoding="UTF-8"?> | | <deployment xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" | xsi:schemaLocation="urn:jboss:bean-deployer bean-deployer_1_0.xsd" | xmlns="urn:jboss:bean-deployer" | name="HelloBeans"> <!-- HERE --> | <bean name="Name1" class="test.Hello"> | <property name="prop">Property</property> | </bean> | </deployment> | | Gives: | <depends>jboss.beans:service=JBossBeanDeployment,name='HelloBeans'</depends> | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880436#3880436 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880436 |
|
From: <ad...@jb...> - 2005-06-06 15:42:37
|
This is really one for the "naming nazis" :-) What do you want to call the bean deployments? I'd suggest something like: Archive Name: mybeans.bar Archive MetaData: META-INF/jboss-beans.xml NonArchive MetaData: *-beans.xml I could also allow these to be changed on the deployer itself through JMX attributes? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880433#3880433 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880433 |
|
From: fabcipriano <nu...@jb...> - 2005-06-06 14:06:41
|
In the Maindeployer.java cvs version 1.74.2.3
The methods stop(DeploymentInfo di) and destroy(DeploymentInfo di) not update the DeploumentInfo.state field with the values DeploymentState.STOPPED and DeploymentState.DESTROYED.
I saw this when I fixed the JSR-88 getRunningModules and after run a jsr88.stop(new TargetModuleID[]{tmid}); the running modules was not updated. See http://jira.jboss.com/jira/browse/JBAS-1870
Are you implementing the JSR-88 plug-in to use MainDeployer or the JSR-77 in the future ? Does someone is working in it ?
Sorry for my english and thanks,
Fabiano.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880410#3880410
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880410
|
|
From: knuterikballestad <nu...@jb...> - 2005-06-06 13:23:06
|
I have successfully been using Hibernate as the persistence layer in my .ear project for some time. I have an .ear project containing a .sar hibernate mapping and a .war webapp. The classes common for these are simply located on my .ear root. So far so good, but If I try to deploy my app on 4.0.2 instead of 4.0.2rc1, I get this error: ERROR [MainDeployer] could not create deployment: file:/D:/Java/JBoss/jboss-4.0.2/server/default/deploy/MyApp.ear/hibernatemapping.sar | org.jboss.deployment.DeploymentException: No ClassLoaders found for: net.sf.hibernate.jmx.HibernateService; - nested throwable: (java.lang.ClassNotFoundException: No ClassLoaders found for: net.sf.hibernate.jmx.HibernateService) | at org.jboss.system.ServiceConfigurator.install(ServiceConfigurator.java:143) | Does anybody here know what changed and/or how to get it to work on 4.0.2? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880409#3880409 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880409 |
|
From: felipeal <nu...@jb...> - 2005-06-06 13:20:54
|
I don't think so, at least not the 1.4.1 version. I installed it and got the following exception when I tried to create a JBoss configuration on the Debug window:
java.lang.NoSuchMethodError: org.eclipse.jdt.internal.debug.ui.launcher.Launcher
Messages.getString(Ljava/lang/String;)Ljava/lang/String;
at org.jboss.ide.eclipse.launcher.ui.configuration.ServerLaunchArguments
Tab.createControl(ServerLaunchArgumentsTab.java:86)
at org.eclipse.debug.internal.ui.launchConfigurations.LaunchConfiguratio
nTabGroupViewer.showTabsFor(LaunchConfigurationTabGroupViewer.java:720)
at org.eclipse.debug.internal.ui.launchConfigurations.LaunchConfiguratio
nTabGroupViewer.showInstanceTabsFor(LaunchConfigurationTabGroupViewer.java:639)
at org.eclipse.debug.internal.ui.launchConfigurations.LaunchConfiguratio
nTabGroupViewer.displayInstanceTabs(LaunchConfigurationTabGroupViewer.java:519)
at org.eclipse.debug.internal.ui.launchConfigurations.LaunchConfiguratio
nTabGroupViewer$5.run(LaunchConfigurationTabGroupViewer.java:471)
at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:69)
at org.eclipse.debug.internal.ui.launchConfigurations.LaunchConfiguratio
nTabGroupViewer.inputChanged(LaunchConfigurationTabGroupViewer.java:488)
at org.eclipse.debug.internal.ui.launchConfigurations.LaunchConfiguratio
nTabGroupViewer.setInput(LaunchConfigurationTabGroupViewer.java:452)
at org.eclipse.debug.internal.ui.launchConfigurations.LaunchConfiguratio
nsDialog.handleLaunchConfigurationSelectionChanged(LaunchConfigurationsDialog.ja
va:788)
at org.eclipse.debug.internal.ui.launchConfigurations.LaunchConfiguratio
nsDialog$3.selectionChanged(LaunchConfigurationsDialog.java:600)
at org.eclipse.jface.viewers.StructuredViewer$3.run(StructuredViewer.jav
a:763)
at org.eclipse.core.internal.runtime.InternalPlatform.run(InternalPlatfo
rm.java:1038)
at org.eclipse.core.runtime.Platform.run(Platform.java:775)
at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:44)
at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:148)
at org.eclipse.jface.viewers.StructuredViewer.firePostSelectionChanged(S
I haven't tried the JBossIDE 1.5M1, but I guess it will fail as well, as this was released a couple of months ago, before the Eclipse 3.1 M7 was available.
-- Felipe
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880408#3880408
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880408
|
|
From: sarangk <nu...@jb...> - 2005-06-06 12:34:29
|
Hi All, I have installed Jboss Appserver 4.0.2 with portal RC 2.0. I have started the server I am able to upload the pdf and doc files but when I try to view that file it gives the following error: 404 - Page Not Found Oops! We can't find the resource you're looking for. What needs to be done to assosiate the the pdf file so that I can view those pdf files from the browser? Thanks in advance. Saravanan.K View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880403#3880403 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880403 |
|
From: <ju...@jb...> - 2005-06-06 09:48:35
|
sourceforge is not longer used anymore, meanwhile you can the anonymous CVS to get the latest tree, later you will be subscribed to the dev CVS. the anon CVS is available with : | cvs -d :pserver:ano...@an...:/cvsroot/jboss co jboss-portal-2.0 | can you send me an email ? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880387#3880387 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880387 |
|
From: <ju...@jb...> - 2005-06-06 09:44:23
|
what do you mean by database chars ? coming from CMS ? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880385#3880385 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880385 |
|
From: sayamaahmed <nu...@jb...> - 2005-06-06 06:59:54
|
Hi, I precomiled the JSPs in our application using an ant build file. I used the jasper2 property for it. The servlets are generated but these files are different from those generated when the servlets are generated on loading the page for the first time. These precompiled files lack some code. The application does not work with the precompiled files. I dont know what the problem is. Please do let me know? I am using jboss-3.2.6. Please do tell me from which version of Tomcat do I need to take the jar files. Thanks and Regards, Sayama View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880369#3880369 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880369 |
|
From: sarangk <nu...@jb...> - 2005-06-06 04:15:49
|
Hi, I have requirement like this. In my portal I would like to have News Managements system on on side and Documets sharing system (that will have set of documents like pdf, doc etc) and the other one will have discussion fourms. Is it possible to design this in a JBoss portal. All I have seen is in the JBoss portal you will be able to see all the portal only in the form of links is it possible to view portal that contains all the porlets info as such. If yes how and what are steps that need to be done to achive that? Thanks in advance. Saravanan.K View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3880365#3880365 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3880365 |
1965 messages has been excluded from this view by a project administrator.
