[Design of JBoss Profiler] - Re: JBoss Profiler 2
by alwinint
Hi,
so far, I was successuflly able to set up the profiler as I see the MBean in the JMX console. Starting works fine, but it seems that the proerties file is completely ignored (which I put in the server's bin directory and included the setting in the run.conf).
Secondly, if I try to issue a stopProfiler or snapshot command, I get:
java.lang.NullPointerException
at org.jboss.profiler.agent.ClassUtil.getClasses(ClassUtil.java:80)
at org.jboss.profiler.agent.Profiler.stopProfiler(Profiler.java:146)
at org.jboss.profiler.connectors.AbstractHandler.handleCommand(AbstractH
andler.java:51)
at org.jboss.profiler.connectors.SocketHandler.invoke(SocketHandler.java
:50)
at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:734)
at org.jboss.remoting.transport.socket.ServerThread.processInvocation(Se
rverThread.java:560)
at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.j
ava:369)
at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.jav
a:165)
at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientI
nvoker.java:163)
at org.jboss.remoting.Client.invoke(Client.java:1550)
at org.jboss.remoting.Client.invoke(Client.java:530)
at org.jboss.remoting.Client.invoke(Client.java:518)
at org.jboss.profiler.client.cmd.Client.main(Client.java:252)
even though I tried to add some classes before (and also set the include proerty in the file). I am using JBoss 4.0.4-GA right now. Is there anything which I can change?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4123356#4123356
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4123356
16 years, 11 months
[Design of JBoss Build System] - VFS build problem
by scott.stark＠jboss.org
What does this mean?
| [starksm@succubus trunk]$ mvn release:prepare -DdryRun=true
| [INFO] Scanning for projects...
| [INFO] Searching repository for plugin with prefix: 'release'.
| WAGON_VERSION: 1.0-beta-2
| [INFO] ----------------------------------------------------------------------------
| [INFO] Building JBoss VFS
| [INFO] task-segment: [release:prepare] (aggregator-style)
| [INFO] ----------------------------------------------------------------------------
| [INFO] [release:prepare]
| [INFO] Resuming release from phase 'rewrite-poms-for-release'
| [INFO] Transforming 'JBoss VFS'...
| [INFO] ------------------------------------------------------------------------
| [ERROR] FATAL ERROR
| [INFO] ------------------------------------------------------------------------
| [INFO] 61
| [INFO] ------------------------------------------------------------------------
| [INFO] Trace
| java.lang.ArrayIndexOutOfBoundsException: 61
| at org.apache.maven.shared.release.phase.RewritePomsForReleasePhase.translateUrlPath(RewritePomsForReleasePhase.java:249)
| at org.apache.maven.shared.release.phase.RewritePomsForReleasePhase.translateScm(RewritePomsForReleasePhase.java:124)
| at org.apache.maven.shared.release.phase.RewritePomsForReleasePhase.transformScm(RewritePomsForReleasePhase.java:61)
| at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transformDocument(AbstractRewritePomsPhase.java:271)
| at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transformProject(AbstractRewritePomsPhase.java:180)
| at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transform(AbstractRewritePomsPhase.java:116)
| at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.simulate(AbstractRewritePomsPhase.java:691)
| at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:190)
| at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:131)
| at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:94)
| at org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:127)
| at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443)
| at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
| at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493)
| at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463)
| at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
| at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:224)
| 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:597)
| 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)
| [INFO] ------------------------------------------------------------------------
| [INFO] Total time: 1 second
| [INFO] Finished at: Thu Jan 24 21:55:40 PST 2008
| [INFO] Final Memory: 8M/140M
| [INFO] ------------------------------------------------------------------------
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4123315#4123315
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4123315
16 years, 11 months
[Design of JBoss jBPM] - Re: Potential enhancement to jbpm
by brittm
Processes are generally defined at a business scope, not at application run time.
A process definition should be built and deployed in it's proper context--that is "Process Definition Lifecycle". Process Definition Lifecycle (and Process Instance Lifecycle for that matter) will rarely coincide with Application Lifecycle, so Application Lifecycle is generally a bad fit for managing either Process Definition Lifecycle or Process Instance Lifecycle.
To put it bluntly, unless your Process Definitions are dynamically generated each time your application starts, the act of starting your application shouldn't be deploying your Definitions.
All that being said, jBPM DOES need to support a user assigned Version/Release number that can be used by the application to make determinations as to UI requirements/various compatibilities/etc. I've recently been forced to bastardize the processDefinition description field to support this:<description>uiVersion=1, release=1|Service Request for leased circuit</description>
...sorry for this last rabbit trail, but Ronald brought it up, and I do hate parsing strings. :-)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4123311#4123311
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4123311
16 years, 11 months
[Design of EJB 3.0] - Re: Nice version conlfict on jboss-ejb3-ext-api-impl
by ALRubinger
This brings up a couple issues.
1) How we resolve the conflict
2) How we continue with ejb3-ext-api-impl (if at all)
1 -
Resolving the conflict with ClusteredImpl may be a bit more involved than it seems because AS5 Beta3 shipped with @Clustered within the ha-client version 1.0.0.BETA1. Beta4 is currently gunning to use the same version, but if Brian's got changes he needs to get into the release, @Clustered will disappear (as it's been moved to ejb3-ext-api).
So we've got three projects tied together (for the time being), ejb3-ext-api, ejb3-ext-api-impl, and ha-client. If we bump up any of these releases for Beta4, we must bump up all. This binding was intended for structural changes to code in ext-api and ext-api-impl.
So resolution depends, then, on what version of ha-client will be used in Beta4. If we stay on 1.0.0.BETA1 then we'd have to backport the annotation impls, unless...
2 -
Moving forward, we'll go with the conventions we've set forth for versioning: 0.2.x should be the next series, not 0.1.4. This way we won't have to increment betas (Beta2 in the case you'd shown isn't really Beta2, its got new featuresets).
However, I thought the point of moving these annotation impls into their own package was for the following benefits:
* Discourage interdependencies within projects
* Allow for separate, frozen lifecycle
* Logically divide code and keep components small
For instance, if both Core and Interceptors need ExcludeClassInterceptorsImpl, wouldn't it be better for them both to depend on an ejb3-ext-api-impl than Core > Interceptors or vise-versa?
I suppose point 2) is a matter of preference.
S,
ALR
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4123290#4123290
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4123290
16 years, 11 months