8:41 a.m.
Hello team,
there are new issues in the jira issues tracker for migrating EAP6->EAP7 thanks to
Eduardo. Currently we have 3 new issues (https://issues.jboss.org/browse/WINDUPRULE-66).
We have two ways we may resolve them:
a) create XSLT - this will take a lot of time, but user may love us for it
b) put there only hint - simple to do.
Not sure which way to go and if we have some time to spend doing XSLT. (estimation is 1
week for 1 XSLT transformation).
10:43 a.m.
I am adding 3rd way:
We could read the EAP 6 config using CLI, and write the EAP 7 config
using CLI.
That would need us to get the location of the EAP 6 dir and the new EAP
7 dir,
and then run both in host controller mode, or how is it called.
Is that viable?
Ondra
On 1.9.2015 15:41, Matej Briskar wrote:
Hello team,
there are new issues in the jira issues tracker for migrating EAP6->EAP7 thanks to
Eduardo. Currently we have 3 new issues (https://issues.jboss.org/browse/WINDUPRULE-66).
We have two ways we may resolve them:
a) create XSLT - this will take a lot of time, but user may love us for it
b) put there only hint - simple to do.
Not sure which way to go and if we have some time to spend doing XSLT. (estimation is 1
week for 1 XSLT transformation).
_______________________________________________
windup-dev mailing list
windup-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/windup-dev
10:45 a.m.
I think that generating the configuration is a good idea. I don't have a
strong preference about how it is done.
On Wed, Sep 2, 2015 at 11:43 AM, Ondrej Zizka <ozizka(a)redhat.com> wrote:
I am adding 3rd way:
We could read the EAP 6 config using CLI, and write the EAP 7 config
using CLI.
That would need us to get the location of the EAP 6 dir and the new EAP
7 dir,
and then run both in host controller mode, or how is it called.
Is that viable?
Ondra
On 1.9.2015 15:41, Matej Briskar wrote:
> Hello team,
> there are new issues in the jira issues tracker for migrating EAP6->EAP7
thanks to Eduardo. Currently we have 3 new issues (
https://issues.jboss.org/browse/WINDUPRULE-66).
>
> We have two ways we may resolve them:
> a) create XSLT - this will take a lot of time, but user may love us for
it
> b) put there only hint - simple to do.
>
> Not sure which way to go and if we have some time to spend doing XSLT.
(estimation is 1 week for 1 XSLT transformation).
> _______________________________________________
> windup-dev mailing list
> windup-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev
_______________________________________________
windup-dev mailing list
windup-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/windup-dev
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
11:39 a.m.
How it's done affects how the user uses it.
A) With the XSLT approach, user will have to point windup to the single
standalone.xml file I guess. But it can be done "statically", nothing
really running.
B) With CLI, the user will point Windup to the 2 directories (EAP 6, EAP
7). And the operation will try to run some CLI.
B is imo more convenient, and also will reuse the existing code handing
the standalone.xml read/write (and take care of namespaces),
but will take longer to implement correctly. So I guess it's something
for later sprints?
Ondra
On 2.9.2015 17:45, Lincoln Baxter, III wrote:
I think that generating the configuration is a good idea. I don't
have
a strong preference about how it is done.
On Wed, Sep 2, 2015 at 11:43 AM, Ondrej Zizka <ozizka(a)redhat.com
<mailto:ozizka@redhat.com>> wrote:
I am adding 3rd way:
We could read the EAP 6 config using CLI, and write the EAP 7 config
using CLI.
That would need us to get the location of the EAP 6 dir and the
new EAP
7 dir,
and then run both in host controller mode, or how is it called.
Is that viable?
Ondra
On 1.9.2015 15:41, Matej Briskar wrote:
> Hello team,
> there are new issues in the jira issues tracker for migrating
EAP6->EAP7 thanks to Eduardo. Currently we have 3 new issues
(https://issues.jboss.org/browse/WINDUPRULE-66).
>
> We have two ways we may resolve them:
> a) create XSLT - this will take a lot of time, but user may love
us for it
> b) put there only hint - simple to do.
>
> Not sure which way to go and if we have some time to spend doing
XSLT. (estimation is 1 week for 1 XSLT transformation).
> _______________________________________________
> windup-dev mailing list
> windup-dev(a)lists.jboss.org <mailto:windup-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/windup-dev
_______________________________________________
windup-dev mailing list
windup-dev(a)lists.jboss.org <mailto:windup-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/windup-dev
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
_______________________________________________
windup-dev mailing list
windup-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/windup-dev
11:08 a.m.
Besides depending on EAP binaries, you would also need an embeddable EAP, and that is only
on WildFly (and doesn’t integrate with windup due to logging issues).
—E
On 02 Sep 2015, at 16:43, Ondrej Zizka <ozizka(a)redhat.com>
wrote:
I am adding 3rd way:
We could read the EAP 6 config using CLI, and write the EAP 7 config using CLI.
That would need us to get the location of the EAP 6 dir and the new EAP 7 dir,
and then run both in host controller mode, or how is it called.
Is that viable?
Ondra
On 1.9.2015 15:41, Matej Briskar wrote:
> Hello team,
> there are new issues in the jira issues tracker for migrating EAP6->EAP7 thanks to
Eduardo. Currently we have 3 new issues (https://issues.jboss.org/browse/WINDUPRULE-66).
>
> We have two ways we may resolve them:
> a) create XSLT - this will take a lot of time, but user may love us for it
> b) put there only hint - simple to do.
>
> Not sure which way to go and if we have some time to spend doing XSLT. (estimation is
1 week for 1 XSLT transformation).
> _______________________________________________
> windup-dev mailing list
> windup-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev
8:38 p.m.
Eduardo,
is it possible to do a system call (instead of direct API usage) to run
a generated CLI script and let AS deal with it?
Or a system call to boot the controller, and then use the REST API?
The reason for that is, that AFAIR, fiddling with standalone.xml was
officially deprecated way of configuring EAP, and the recommended,
forward compatible way, was officially CLI commands.
Is that still the case?
Thanks,
Ondra
On 2.9.2015 18:08, Eduardo Martins wrote:
Besides depending on EAP binaries, you would also need an embeddable
EAP, and that is only on WildFly (and doesn’t integrate with windup due to logging
issues).
—E
> On 02 Sep 2015, at 16:43, Ondrej Zizka <ozizka(a)redhat.com> wrote:
>
> I am adding 3rd way:
>
> We could read the EAP 6 config using CLI, and write the EAP 7 config using CLI.
>
> That would need us to get the location of the EAP 6 dir and the new EAP 7 dir,
> and then run both in host controller mode, or how is it called.
>
> Is that viable?
>
> Ondra
>
>
> On 1.9.2015 15:41, Matej Briskar wrote:
>> Hello team,
>> there are new issues in the jira issues tracker for migrating EAP6->EAP7
thanks to Eduardo. Currently we have 3 new issues
(https://issues.jboss.org/browse/WINDUPRULE-66).
>>
>> We have two ways we may resolve them:
>> a) create XSLT - this will take a lot of time, but user may love us for it
>> b) put there only hint - simple to do.
>>
>> Not sure which way to go and if we have some time to spend doing XSLT.
(estimation is 1 week for 1 XSLT transformation).
>> _______________________________________________
>> windup-dev mailing list
>> windup-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/windup-dev
5:42 a.m.
On 10 Sep 2015, at 02:38, Ondrej Zizka <ozizka(a)redhat.com>
wrote:
Eduardo,
is it possible to do a system call (instead of direct API usage) to run a generated CLI
script and let AS deal with it?
Or a system call to boot the controller, and then use the REST API?
Suppose you could do that, and the development of such functionalities would be less
effort than developing the rules to handle the migration of 3 subsystems, then before you
could invoke :migrate you would still need to parse and transform the old subsystem XML
into management ops, i.e. need all EAP subsystem parsers. And you would also need to
somehow transform the :migrate result into high level Windup report entries (targeting the
source of migration, the XML).
If you are trying yo avoid the XML rules with XSLT, due to XSLT complexity, an alternative
would be Non XML Windup rules using a generic XML API, integrating the code logic of
:migrate ops, which is short and not very complex. IMHO much less effort than what you
propose above.
The reason for that is, that AFAIR, fiddling with standalone.xml was
officially deprecated way of configuring EAP, and the recommended, forward compatible way,
was officially CLI commands.
Is that still the case?
Recommended != mandatory, we certainly need to cover the migration of XML server configs,
it’s the basic EAP config process, and is supported by Red Hat.
—E
9:01 a.m.
Hi, I didn't notice your reply earlier.
I don't mean the :migrate ops in particular. I mean CLI in general. That
is, instead of changing the target server's standalone.xml, we would do
the changes over CLI. Individual steps for individual resources. Not
just calling :migrate.
You wrote we need to cover XML server configs. I guess you mean the
source server's XML files. So we could read these into the graph, and
then generate (and perform) a CLI script which would set them up.
The problem with XSLT is not complexity, but rather namespaces. XSLT 1.0
is quite poor with namespaces. And if mixed with including the .xsl
files in other .xsl, it's highly error prone.
Ondra
On 10.9.2015 12:42, Eduardo Martins wrote:
> On 10 Sep 2015, at 02:38, Ondrej Zizka <ozizka(a)redhat.com>
wrote:
>
> Eduardo,
>
> is it possible to do a system call (instead of direct API usage) to run a generated
CLI script and let AS deal with it?
> Or a system call to boot the controller, and then use the REST API?
>
Suppose you could do that, and the development of such functionalities would be less
effort than developing the rules to handle the migration of 3 subsystems, then before you
could invoke :migrate you would still need to parse and transform the old subsystem XML
into management ops, i.e. need all EAP subsystem parsers. And you would also need to
somehow transform the :migrate result into high level Windup report entries (targeting the
source of migration, the XML).
If you are trying yo avoid the XML rules with XSLT, due to XSLT complexity, an
alternative would be Non XML Windup rules using a generic XML API, integrating the code
logic of :migrate ops, which is short and not very complex. IMHO much less effort than
what you propose above.
> The reason for that is, that AFAIR, fiddling with standalone.xml was officially
deprecated way of configuring EAP, and the recommended, forward compatible way, was
officially CLI commands.
> Is that still the case?
>
Recommended != mandatory, we certainly need to cover the migration of XML server configs,
it’s the basic EAP config process, and is supported by Red Hat.
—E
3393
days inactive
3422
days old
7 comments
4 participants
participants (4)
-
Eduardo Martins -
Lincoln Baxter, III -
Matej Briskar -
Ondrej Zizka