Re: [jboss-dev] Re: [jbosstools-dev] JSR-77 Summary
by Max Rydahl Andersen
> Before, when we discussed the JMX option, and the potential for a REST
> API, I was working under the assumption that tools only needed a basic
> set of operations.
Yes, basic:
List deployed apps/modules/resources
Stop/start apps/modules/resources
Deploy/hotdeploy apps/modules/resources
> Once this thread started talking about JSR-77 management functions,
> this to me says the profile service is the way forward.
Because we don't know of any other API we can use to get information.
> As to the tomcat API, I don't see how it provides anything close to
> JSR-77.
The tomcat API provides the 3 things from above afaics.
/max
>
>> Neither JSR-77 or JSR-88 are going to be part of EE in the future.
>>
>> The profileservice certainly is available remotely, but I thought we
>> were focusing on the hotdeployment jmx based api as discussed in:
>> https://jira.jboss.org/jira/browse/JBAS-6330
I have asked *many* times now and *noone* have been able to show me
Profileservice being available remotely without a very *tight* dependency
on the exact version of AS plus noone have been able to tell us the
dependencies we need (except a very fuzzy maven dependency set which
were *big*
and unique per version).
If the tools have to be updated every time there is a minor release then
this is a very fragile system to depend on.
>> If we want this mapped into a resty type api ala the tomcat then that
>> needs to be defined.
If there is some other API we can use great, but a resty type API sounds
to me like the best and only option that would not be fragile.
/max
>>
>> Max Rydahl Andersen wrote:
>>> Anyone out there listening ?
>>>
>>> Should we just drop this idea of having good remote control over AS
>>> from tooling ?
>>>
>>> /max
>>>
>>> Max Rydahl Andersen wrote:
>>>>>> Is JSR-77 supported ? Will it be in EAP 5 ?
>>>>>> JSR-288 had similar issues earlier - are they fixed ? will they
>>>>>> be fixed ?
>>>>>
>>>>> JSR-77 is required for EE, but it is very out of date, and will
>>>>> likely get killed in a future release. JSR-88 is already scheduled
>>>>> for removal in EE7.
>>>> So we should not even consider using it for remote access ?
>>>>>> What are the alternatives, if any ?
>>>>>
>>>>> If you guys need advanced management functionality, it sounds like
>>>>> the Profile Service is going to be what you need.
>>>> Sure, but profile service is not available to us remotely.
>>>>
>>>> Btw. I don't consider any of the things we want to do very advanced
>>>> - we don't want to be another JON.
>>>>
>>>> Something basic and simple as i.e. Tomcat Management API would be
>>>> enough for us afaics.
>>>>
>>>> http://tomcat.apache.org/tomcat-5.5-doc/manager-howto.html
>>>>
>>>> It provides a simple http api to list, start/stop/undeploy
>>>> applications/resources (both local and remote resources)
>>>>
>>>> btw. this is not just for *us* this is for the greater good of AS :)
>>>>
>>>> /max
>>
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
16 years, 8 months
Re: [jboss-dev] Re: [jbosstools-dev] JSR-77 Summary
by Rob Stryker
JSR-77 type management isn't exactly crazy-go-nuts-complicated (at least
it doesn't appear so to me. Under the hood it could be I suppose, but
what needs to be exposed doesn't seem that bad). What doesn't seem done
is just the ability to start / stop / undeploy / redeploy a module via
JMX. I would say this set *is* a basic set of features, and it is pretty
much exactly what JSR-77 outlines.
Whether or not it's part of the future JEE doesn't mean it's not a good
management layer to expose. In all honesty I don't know if it's a great
one or not... but all I'd like to have is the ability to start / stop /
undeploy / redeploy via JMX, and parts of 77 do that ;)
Question: If something can be done via profile service, how hard / how
much work for the AS team is it to just expose that via a JMX interface?
Is this a lot of work, or do we just need to define the interface and
then it's pretty simple? The reason I ask is because the tooling likes
JMX much more than compiling against different versions of profile service.
- Rob
Jason T. Greene wrote:
> Before, when we discussed the JMX option, and the potential for a REST
> API, I was working under the assumption that tools only needed a basic
> set of operations. Once this thread started talking about JSR-77
> management functions, this to me says the profile service is the way
> forward.
>
> As to the tomcat API, I don't see how it provides anything close to
> JSR-77.
>
> Scott Stark wrote:
>> Neither JSR-77 or JSR-88 are going to be part of EE in the future.
>>
>> The profileservice certainly is available remotely, but I thought we
>> were focusing on the hotdeployment jmx based api as discussed in:
>> https://jira.jboss.org/jira/browse/JBAS-6330
>>
>> If we want this mapped into a resty type api ala the tomcat then that
>> needs to be defined.
>>
>> Max Rydahl Andersen wrote:
>>> Anyone out there listening ?
>>>
>>> Should we just drop this idea of having good remote control over AS
>>> from tooling ?
>>>
>>> /max
>>>
>>> Max Rydahl Andersen wrote:
>>>>>> Is JSR-77 supported ? Will it be in EAP 5 ?
>>>>>> JSR-288 had similar issues earlier - are they fixed ? will they
>>>>>> be fixed ?
>>>>>
>>>>> JSR-77 is required for EE, but it is very out of date, and will
>>>>> likely get killed in a future release. JSR-88 is already scheduled
>>>>> for removal in EE7.
>>>> So we should not even consider using it for remote access ?
>>>>>> What are the alternatives, if any ?
>>>>>
>>>>> If you guys need advanced management functionality, it sounds like
>>>>> the Profile Service is going to be what you need.
>>>> Sure, but profile service is not available to us remotely.
>>>>
>>>> Btw. I don't consider any of the things we want to do very advanced
>>>> - we don't want to be another JON.
>>>>
>>>> Something basic and simple as i.e. Tomcat Management API would be
>>>> enough for us afaics.
>>>>
>>>> http://tomcat.apache.org/tomcat-5.5-doc/manager-howto.html
>>>>
>>>> It provides a simple http api to list, start/stop/undeploy
>>>> applications/resources (both local and remote resources)
>>>>
>>>> btw. this is not just for *us* this is for the greater good of AS :)
>>>>
>>>> /max
>>>
>>
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
>
>
16 years, 8 months
Re: [jboss-dev] Re: [jbosstools-dev] JSR-77 Summary
by Max Rydahl Andersen
>> Is JSR-77 supported ? Will it be in EAP 5 ?
>> JSR-288 had similar issues earlier - are they fixed ? will they be
>> fixed ?
>
> JSR-77 is required for EE, but it is very out of date, and will likely
> get killed in a future release. JSR-88 is already scheduled for
> removal in EE7.
So we should not even consider using it for remote access ?
>
>> What are the alternatives, if any ?
>
> If you guys need advanced management functionality, it sounds like the
> Profile Service is going to be what you need.
Sure, but profile service is not available to us remotely.
Btw. I don't consider any of the things we want to do very advanced - we
don't want to be another JON.
Something basic and simple as i.e. Tomcat Management API would be enough
for us afaics.
http://tomcat.apache.org/tomcat-5.5-doc/manager-howto.html
It provides a simple http api to list, start/stop/undeploy
applications/resources (both local and remote resources)
btw. this is not just for *us* this is for the greater good of AS :)
/max
16 years, 8 months
Migration to Eclipse 3.5/Galileo
by Max Rydahl Andersen
Hi,
I looked through issues around Eclipse 3.5/Galieleo today - commented
and added to https://jira.jboss.org/jira/browse/JBIDE-4123
Most things looks trivial so that is the good news.
The bad news is that Hibernate Dali integration, JSF/VPE's usage of
javascript and Strut dependency on removed Debug API looks like possible
big issues.
But I do though believe they are all fixable.
I therefore suggest that we ASAP(monday/tuesday?) move our trunk builds
onto the latest I-builds of Galileo (required to get VPE to work) so we
can get everyone on to Galileo ASAP.
When we do this please keep an eye out for
http://hudson.jboss.org/hudson/view/JBossTools/job/jbosstools-nightly-3.1...,
to see if changes breaks others!
/max
16 years, 8 months
Compile errors in jbosstools trunk
by Snjezana Peco
Currently there are some compile errors in the
org.jboss.tools.vpe.ui.test and org.jboss.tools.jsf.vpe.seam plugin.
Snjeza
16 years, 8 months
