August 2007 - jboss-dev-forums - Jboss List Archives

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Count Messages with Selector and Edit Message

by hendra_netm

Hi Tim, Thank you for your answer. I just signed the contributor agreement. By sending the patch direct, do you mean by using email or how? Do I send 7 files mentioned above + Queue-xmbean.xml + QueueTest.java, so you need to put the files into appropriate directory, or do I send a whole directory structure? Best Regards, Hendra View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4075207#4075207 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4075207

18 years, 7 months

1
0
0 / 0

[Design of JBoss Portal] - Re: Starting the detachment of portal common

by julien＠jboss.com

I moved the classes org.jboss.portal.Mode and org.jboss.portal.WindowState in a portal module of the common module. The idea is that those classes are related to the portal and very generic and are used throughout the whole code base (like in the portlet container). The resulting jar is named portal-common-portal-lib.jar. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4075201#4075201 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4075201

18 years, 7 months

1
0
0 / 0

[Design of JBoss Build System] - Re: Using jdocbook

by nbhatia

anonymous wrote : | "nbhatia" wrote: | 1) I don't see images copied over from src\main\resources\shared\images to target | "steve.ebersole(a)jboss.com" wrote: | Why would they be? | Sorry for the confusion. This has nothing to do with PDF generation. I will need the images for the html generation and I don't see them anywhere in the target folder. They are available in the src folder mentioned above. 2. Got the point about MalformedURLException coming from FOP. Thanks. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4075200#4075200 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4075200

18 years, 7 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Build broken - weave exception

by alesj

Since yesterday I get this when running MC build: | [INFO] ---------------------------------------------------------------------------- | [INFO] Building JBoss Deployers Client | [INFO] task-segment: [install] | [INFO] ---------------------------------------------------------------------------- | [INFO] [resources:resources] | [INFO] Using default encoding to copy filtered resources. | [INFO] [compiler:compile] | [INFO] Compiling 1 source file to C:\projects\microcontainer\deployers-client\target\classes | [INFO] [jboss-retro:weave {execution: weave-classes}] | [INFO] Weaving classes in: C:\projects\microcontainer\deployers-client\target\classes | [INFO] 17.8.2007 14:52:05 org.jboss.weaver.Main main | [INFO] WARNING: null | [INFO] Weaving complete. | [INFO] [resources:testResources] | [INFO] Using default encoding to copy filtered resources. | [INFO] [compiler:testCompile] | [INFO] Compiling 4 source files to C:\projects\microcontainer\deployers-client\target\tests-classes | [INFO] [jboss-retro:weave-tests {execution: weave-test-classes}] | [INFO] Weaving classes in: C:\projects\microcontainer\deployers-client\target\tests-classes | [INFO] ------------------------------------------------------------------------ | [ERROR] BUILD ERROR | [INFO] ------------------------------------------------------------------------ | [INFO] Error during weave: org.apache.maven.plugin.MojoExecutionException: There were errors during the weave | [INFO] ------------------------------------------------------------------------ | [INFO] Trace | org.apache.maven.lifecycle.LifecycleExecutionException: Error during weave: org.apache.maven.plugin.MojoExecutionException: There were errors during the weave | at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:564) | at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) | at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) | at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) | at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) | at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) | at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) | at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) | at org.apache.maven.cli.MavenCli.main(MavenCli.java:280) | 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.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) | at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) | at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) | at org.codehaus.classworlds.Launcher.main(Launcher.java:375) | Caused by: org.apache.maven.plugin.MojoExecutionException: Error during weave: org.apache.maven.plugin.MojoExecutionException: There were errors during the weave | at org.jboss.maven.plugins.retro.WeaveMojo.execute(WeaveMojo.java:91) | at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443) | at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) | ... 16 more | [INFO] ------------------------------------------------------------------------ | [INFO] Total time: 1 minute 20 seconds | [INFO] Finished at: Fri Aug 17 14:52:06 CEST 2007 | [INFO] Final Memory: 20M/47M | [INFO] ------------------------------------------------------------------------ | Retro is back on ... but breaks? ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4075199#4075199 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4075199

18 years, 7 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Count Messages with Selector and Edit Message

by timfox

Hi Hendra- When you're done, just send me a patch direct. You'll also need to sign a contributor agreement if you haven't done so already: http://labs.jboss.com/community/contributeCode.html It's probably too late to get it in 1.4.0.CR2, but we may be able to get it in 1.4.0.GA Thanks :) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4075188#4075188 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4075188

18 years, 7 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Count Messages with Selector and Edit Message

by hendra_netm

Hi guys, I have download JBM from trunk in SVN server, and modified the following files: org.jboss.jms.server.destination.QueueMBean.java org.jboss.jms.server.destination.QueueService.java org.jboss.jms.server.destination.ManagedQueue.java org.jboss.messaging.core.contract.PersistenceManager.java org.jboss.messaging.core.impl.JDBCPersistenceManager.java org.jboss.messaging.core.contract.Channel org.jboss.messaging.core.impl.ChannelSupport >From the wiki developer site, I read that I need to create test cases. I think I will just modified this file: org.jboss.test.messaging.jms.QueueTest.java Is that ok, or should I created new test file? After that what should I do? Upload it to the SVN server or there is another step that need to be done? Thank you in advance for your help. Best Regards, Hendra View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4075181#4075181 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4075181

18 years, 7 months

1
0
0 / 0

[Design of JBoss Portal] - Re: WANTED: Input from administrators & developers

by Antoine_h

Hello, back to this post, when looking at the JBoss ON monitoring features... I noticed something : about the xml export/import of the portal description. I think the whole thing may be seen an other way. Situation : Since the begining, I understand it is an easy way to provide admin interface. and I understand very well it is important that new people that want to give a try to JBoss portal can play around with the portal. Out of the box. and even for dev, the admin GUI is very usefull for prototyping. Since the begining, I don't like this database ;-).... I don't understand why "all this"... Problem : 1) no use of it, for portal that goes to prod For a portal in prod : the new pages/windows/portlets will go through a intensive integration and testing work. No "dev to prod" team will use the admin interface to modify anything. They will work on the War/Sar given by the dev (after testing), and so every thing rely on the xml descriptor. in a "simple portal" in prod : minimum integration and testing are done : if there is a problem, it goes back to the dev team for resolution. in big portal, in big companies : huge integration and testing process, with at least a step into a stagging environement, etc... So relying of War/Sar (with xml descriptors in it) is much more easy than [War/Sar + database] (that's why I don't use the database... never... just playing with the GUI, once in a while, when a new version comes out... just to see "what's new"...) 2) the database is a problem in dev to prod cycle dev to prod is a cycle, going back and forth till the new things works fine. so having each time to "carry a database" is a burden 3) no database to run a portal the users in a LDAP the cms in a... cms legacy or other choice of the company (open source... or vendors). ... and no database for running a portal. Out of 3 portal I worked on, 2 where from the start on this architecture. one : users in legacy system, cms = Filenet second : users in ldap, cms = legacy + choice for a new one going on third : my own... will use ldap and a cms like Alfresco or Nuxeo, as soon as I can so, I guess having a portal that avoid to ask for a special "one more database" is a good thing. 4) a burden for HA and admin to monitor this "one more database" For dev, having a "one more database" is easy... for prod, it has a cost : one more thing to care at - architecture of system - install, integration tests - monitoring - writting procedures for SLA, case of failure management when it comes to HA and clusters of database ... work and cost is increasing : - multiplication of database server - multiplication of things to monitor on every day supervision a lot to take care of every days Resolution proposal To consider the database way of working as an option. Make the portal work only with the descriptor Admin GUI on files (the war/sar files) : - read only, for checking things (debug, etc...) - write : on a special storing place, to then get the files (or a part of one file) and integrate in the dev working files. - write can be done later... not fundamental... and quite complicate for storing somewhere and then impact the dev files Admin GUI on database : - optionnal (separate package for easy installation and desinstallation) - for out of the box and discovery : what a nice portal ! - prototyping : working with marketing/operationnal on the design, for a proof of concept when "selling a project", etc... As far as there is a export/import feature... make the database an option is an interesting "next step". For prod and big portal in companies : it is a good thing. ok, that's a long post : you understand that "since the beginning, I don't like this database". now, after a few portal and real prod situation in companies, with cluster for HA, I know why I don't like it. I don't like it, but I agree the Admin GUI is a major feature for "out of the box" portal. This is very important as for any open source project. The idea is to find a way to comply to both needs : out of the box, and a portal that is built for prod hope it helps (whatever is my personnal "I like")... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4075168#4075168 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4075168

18 years, 7 months

1
0
0 / 0

[Design of JBoss Portal] - Re: Starting the detachment of portal common

by julien＠jboss.com

actually I don't think we plan to detach security as 2.8 should not use it in the future View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4075145#4075145 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4075145

18 years, 7 months

1
0
0 / 0

[Design of JBoss Portal] - Test module detached

by julien＠jboss.com

This module is now detached. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4075144#4075144 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4075144

18 years, 7 months

1
0
0 / 0

[Design of JBoss Portal] - Re: Starting the detachment of portal common

by julien＠jboss.com

jems, widget, portlet, cms, bridge, portlet-federation, search, widget, workflow, wsrp, registration, faces, security we'll leave in : format and theme as we don't plan reuse View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4075143#4075143 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4075143

18 years, 7 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums August 2007